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Conventions  and  Terminology 


Conventions 

The  notation,  formatting  and  conventions  used  in  this  Protection  Profile  are 
largely  consistent  with  those  used  in  version  2.1  of  the  Common  Criteria  (CC). 
Selected  presentation  choices  are  discussed  here  to  aid  the  Protection  Profile  user. 

The  CC  allows  several  operations  to  be  performed  on  functional  requirements; 
refinement,  selection,  assignment,  and  iteration  are  defined  in  paragraph  2.1.4  of 
Part  2  of  the  CC.  Each  of  these  operations  is  used  in  this  Protection  Profile. 


The  refinement  operation  is  used  to  add  detail  to  a  requirement,  and  thus 
further  restricts  a  requirement.  Refinement  of  security  requirements  is  denoted 
by  bold  text.  For  an  example,  see  FMT_SMR.  1  in  this  Protection  Profile. 


The  selection  operation  is  used  to  select  one  or  more  options  provided  by  the 
CC  in  stating  a  requirement.  Selections  are  denoted  by  underlined  italicized 
text.  For  an  example,  see  FDP_RIP.  1  in  this  Protection  Profile. 


The  assignment  operation  is  used  to  assign  a  specific  value  to  an  unspecified 
parameter,  such  as  the  length  of  a  password.  Assignment  is  indicated  by 
showing  the  value  in  square  brackets,  [  assignment_value  ].  For  an  example, 
see  FIA_AFF.l  in  this  Protection  Profile. 


The  iteration  operation  is  used  when  a  component  is  repeated  with  varying 
operations.  Iteration  is  denoted  by  showing  the  iteration  number  in 
parenthesis  following  the  component  identifier,  (iteration_number).  For 
example,  see  FDP_IFC  in  this  Protection  Profile. 


The  security  target  writer  operation  is  used  to  denote  points  in  which  the 
final  determination  of  attributes  is  left  to  the  security  target  writer.  Security 
target  writer  operations  are  indicated  by  the  words  {determined  by  the  security 
target  writers}  in  braces.  For  example,  see  FIA_ATD.l  in  this  Protection 
Profile. 

As  a  vehicle  for  providing  a  further  understanding  of  and  context  for  functional 
requirements,  “Requirements  Overview”  sections  have  been  selectively  added  to 
this  Protection  Profile.  When  they  appear  in  the  text,  these  overviews  precede 
either  a  component  or  set  of  components.  They  provide  a  discussion  of  the 
relationship  between  security  requirements  so  that  the  Protection  Profile  user  can 
see  why  a  component  or  group  of  components  was  chosen  and  what  effect  it  is 


expected  to  have  as  a  group  of  related  functions.  As  an  example,  see  the 
Requirements  Overview  which  precedes  the  ADV_RCR.l  assurance  component. 

Application  Notes  are  provided  to  help  the  developer,  either  to  clarify  the  intent  of 
a  requirement,  identify  implementation  choices,  or  to  define  “pass-fail”  criteria 
for  a  requirement.  For  those  components  where  Application  Notes  are 
appropriate,  the  Application  Notes  will  follow  the  requirement  component.  For  an 
example,  see  the  Application  Note  which  follows  FMT_MSA.3  in  this  Protection 
Profile. 

Terminology 

In  the  Common  Criteria,  many  terms  are  defined  in  Section  2.3  of  Part  1.  The 
following  are  a  subset  of  those  definitions.  They  are  listed  here  to  aid  the  user  of 
the  Protection  Profile. 


User  —  Any  entity  (human  user  or  external  IT  entity)  outside  the  TOE  that 
interacts  with  the  TOE. 


Human  user  —  Any  person  who  interacts  with  the  TOE. 


External  IT  entity  —  Any  IT  product  or  system,  untrusted  or  trusted,  outside 
of  the  TOE  that  interacts  with  the  TOE. 


Role  —  A  predefined  set  of  rules  establishing  the  allowed  interactions  between 
a  user  and  the  TOE. 


Identity  —  A  representation  (e.g.  a  string)  uniquely  identifying  an  authorized 
user,  which  can  either  be  the  full  or  abbreviated  name  of  that  user  or  a 
pseudonym. 


Authentication  data  —  Information  used  to  verify  the  claimed  identity  of  a 
user. 


VI 


From  the  above  definitions  given  by  the  CC,  the  following  terms  can  be  derived: 


Authorized  external  IT  entity  -  Any  IT  product  or  system,  outside  the  scope 
of  the  TOE  that  may  administer  the  security  parameters  of  the  TOE.  Such 
entities  are  not  subject  to  any  access  control  requirements  once  authenticated 
to  the  TOE  and  are  therefore  trusted  to  not  compromise  the  security  policy 
enforced  by  the  TOE. 


Authorized  Administrator  -  A  role  which  human  users  may  be  associated 
with  to  administer  the  security  parameters  of  the  TOE.  Such  users  are  not 
subject  to  any  access  control  requirements  once  authenticated  to  the  TOE  and 
are  therefore  trusted  to  not  compromise  the  security  policy  enforced  by  the 
TOE. 


vii 


Document  Organization 


Section  1  is  the  introductory  material  for  the  Protection  Profile. 

Section  2  provides  a  general  definition  for  application-filter  firewalls. 

Section  3  is  a  discussion  of  the  expected  environment  for  the  firewall,  in 
particular  the  assumptions  that  must  be  true  about  aspects  such  as  physical, 
personnel,  and  connectivity  conditions.  This  section  then  defines  the  set  of  threats 
that  are  to  be  addressed  by  either  the  technical  countermeasures  implemented  in 
the  firewall’s  hardware  and  software,  or  through  the  environmental  controls. 

Section  4  defines  the  security  objectives  for  both  the  firewall  and  the  environment 
in  which  the  firewall  resides. 

Section  5  contains  the  functional  and  assurance  requirements  derived  from  the 
Common  Criteria,  Part  2  and  Part  3,  respectively,  that  must  be  satisfied  by  the 
firewall. 

Section  6  provides  a  rationale  to  explicitly  demonstrate  that  the  IT  security 
objectives  satisfy  the  threats.  The  section  then  explains  how  the  set  of 
requirements  are  complete  relative  to  the  objectives;  that  each  security  objective 
is  addressed  by  one  or  more  relevant  component  requirements. 

References  are  provided  as  background  material  for  further  investigation  by 
interested  users  of  the  Protection  Profile. 

Acronyms  are  provided  to  facilitate  comprehension  of  frequently  used  terms. 


Application-Level  Firewall  Protection  Profile 


1 _ PROTECTION  PROFILE  (PP)  INTRODUCTION 

1.1  PP  IDENTIFICATION 

1  Title:  U.  S.  Department  of  Defense  Application-Level  Firewall  Protection  Profile 
for  Medium  Robustness  Environments 

2  Sponsor:  National  Security  Agency  (NSA) 

3  Authors:  Kathy  V.  Dolan,  NSA;  Patricia  A.  Wright,  NSA;  Rita  R.  Montequin, 
NSA;  Chuck  Hall,  NSA 

4  CC  Version:  CC  Version  2.1 

5  Registration:  <to  be  provided  upon  registration> 

6  PP  Version:  Version  1.0,  dated  June  2000 

7  Keywords:  information  flow  control,  firewall,  proxy  server,  protection  profile 

1.2  PP  OVERVIEW 

8  This  Application  Level  Firewall  Protection  Profile  defines  the  minimum  security 
requirements  for  firewalls  used  by  U.  S.  Government  organizations,  specifically 
the  Department  of  Defense,  handling  unclassified  or  sensitive  but  unclassified 
information  for  Mission-Critical  Categories  in  a  moderate -risk  environment. 
Firewalls  may  consist  of  one  or  more  devices  that  act  as  part  of  an  organization’s 
overall  security  defense  by  isolating  an  organization’s  internal  network  from  the 
Internet  or  other  external  networks.  The  Protection  Profile  defines  the 
assumptions  about  the  security  aspects  of  the  environment  in  which  the  firewall 
will  be  used,  defines  the  threats  that  are  to  be  addressed  by  the  firewall,  defines 
implementation-independent  security  objectives  of  the  firewall  and  its 
environment,  defines  the  functional  and  assurance  requirements  to  meet  those 
objectives,  and  provides  a  rationale  demonstrating  how  the  requirements  meet  the 
security  objectives. 
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1.3  RELATED  PROTECTION  PROFILES 

9  U.S.  Government  Traffic-Filter  Firewall  Protection  Profile  for  Low-Risk 
Environments  [2]. 

10  U.S.  Department  of  Defense  Traffic-Filter  Firewall  Protection  Profile  for  Medium 
Robustness  Environments  [7] . 

11  U.S.  Department  of  Defense  Application-level  Eirewall  Protection  Profile  for 
Basic  Robustness  Environments  [6]. 
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TARGET  OF  EVALUATION  (TOE)  DESCRIPTION 


12  The  purpose  of  a  firewall  is  to  provide  controlled  and  audited  access  to  services, 
both  from  inside  and  outside  an  organization’s  network,  by  allowing,  denying, 
and/or  redirecting  the  flow  of  data  through  the  firewall.  Although  there  are  a 
number  of  firewall  architectures  and  technologies,  firewalls  basically  fall  into  two 
major  categories:  traffic-filter  and  application-level  firewalls.  This  Protection 
Profile  specifies  the  minimum  security  requirements  for  TOEs  composed  of  an 
application-level  firewall. 

13  The  TOE  mediates  information  flows  between  clients  and  servers  located  on 
internal  and  external  networks  governed  by  the  TOE.  TOEs  may  employ 
proxies  to  screen  information  flows.  Proxy  servers  on  the  TOE,  for  services  such 
as  ETP  and  Telnet,  require  authentication  at  the  TOE  by  client  users  before 
requests  for  such  services  can  be  authorized.  Thus,  only  valid  requests  are  relayed 
by  the  proxy  server  to  the  actual  server  on  either  an  internal  or  external  network. 

14  TOEs  meeting  this  Protection  Profile  additionally  impose  traffic-filtering  controls 
on  information  flows  mediated  by  the  TOE.  Information  flows  between  clients 
and  servers  according  to  the  site’s  security  policy  rules.  By  default,  these  security 
policy  rules  deny  all  inbound  and  outbound  information  flows.  Only  an  authorized 
administrator  has  the  authority  to  change  the  security  policy  rules. 

15  Users  of  the  TOE  consist  of  human  users  and  host-like  entities,  called  external  IT 
entities.  Human  users  may  or  may  not  be  associated  with  the  single  role  on  the 
TOE  for  authorized  administrators.  If  the  information  flow  security  policy  rules 
permit  human  users  (who  are  not  authorized  administrators)  on  an  internal  or 
external  network  to  send  and  receive  information  to  ETP  or  Telnet  servers  on  an 
external  or  internal  network,  respectively,  such  users  will  have  to  be  identified 
and  authenticated  (using  a  single-use  authentication  mechanism)  by  the  TOE 
before  information  is  relayed  by  the  proxy  server  on  the  TOE  to  the  ETP  or  Telnet 
server.  Of  the  human  users,  only  authorized  administrators  may  access  the  TOE 
through  remote  means  from  an  internal  or  external  network.  If  an  authorized 
administrator  accesses  the  TOE  remotely,  and  after  successful  identification  and 
authentication  (using  a  single-use  authentication  mechanism),  a  channel  using 
Triple  DES  encryption  with  securely  generated  and  distributed  key  values  must  be 
used.  In  addition  to  remote  access,  and  after  successful  identification  and 
authentication,  authorized  administrators  may  access  the  TOE  through  local 
means  without  encryption,  such  as  through  a  console  (that  may  be  included  as  part 
of  the  TOE).  Though  not  recommended,  the  human  users  who  are  not  authorized 
administrators  may  identify  and  authenticate  from  a  local  console  to  use  non¬ 
security  functions  on  the  TOE.  The  only  security  functions  available  to  human 
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users  who  are  not  authorized  administrators  are  the  controlled  usage  of  the 
identification  and  authentication  functions. 

16  External  IT  entities  sending  information  through  the  TOE  do  not  have  to  be 
identified  and  authenticated,  unless  those  functions  are  supported  by  the 
underlying  service  (e.g.,  ETP).  However,  external  IT  entities  attempting  to  send 
information  to  the  TOE  must  always  be  identified  and  authenticated.  Those 
external  IT  entities  that  are  successfully  identified  and  authenticated  (using  a 
single-use  authentication  mechanism)  are  authorized  external  IT  entities.  This 
subset  of  the  external  IT  entities  are  permitted  to  perform  a  limited  number  of 
security  functions.  They  are  “authorized”  to  violate  the  TSP  in  a  well  understood 
and  permitted  manner.  A  router  sending  routing  table  updates  to  the  TOE,  serves 
as  an  example  of  an  authorized  external  IT  entity.  This  router  would  identify 
itself  to  the  TOE  and  then  use  a  single-use  authentication  mechanism  to 
authenticate.  The  TOE  would  then  accept  routing  table  updates  from  the 
authorized  external  IT  entity.  There  are  no  requirements  mandating  authorized 
external  IT  entities. 

17  Audit  trail  data  is  stamped  with  a  dependable  date  and  time  when  recorded.  Audit 
events  include  modifications  to  the  group  of  users  associated  with  the  authorized 
administrator  role,  all  use  of  the  identification  and  authentication  mechanisms 
(including  any  attempted  reuse  of  authentication  data),  all  information  flow 
control  decisions  made  by  the  TOE  according  to  the  security  policy  rules,  and  the 
use  of  all  security  functions.  If  the  audit  trail  becomes  filled,  then  the  only 
auditable  events  that  may  be  performed  are  those  performed  by  the  authorized 
administrator.  The  TOE  includes  tools  to  perform  searching  and  sorting  on  the 
collected  audit  trail  data  according  to  attributes  of  the  data  recorded  and  ranges  of 
some  of  those  attributes. 
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TOE  SECURITY  ENVIRONMENT 


18  Protection  Profile-compliant  TOEs,  for  the  Department  of  Defense,  must  provide 
appropriate  security  to  process  unclassified  or  sensitive  but  unclassified 
information  in  the  Mission-Critical  Categories.  Mission-Critical  Categories  refer 
to  DoD  systems  that  handle  information  vital  to  the  operational  readiness  or 
mission  effectiveness  of  deployed  and  contingency  forces  in  terms  of  both  content 
and  timeliness.  It  is  assumed  that  the  threat  to  information  designated  as  Mission- 
Critical,  by  nature,  is  greater  and  subject  to  greater  risk  for  disclosure  and/or 
corruption  by  unauthorized  parties  as  indicated  in  the  Protection  Profile  by  the 
assumption  A.MODEXP.  Information  and  information  systems  in  the  Mission- 
Critical  Categories  must  maintain  the  appropriate  level  of  confidentiality, 
integrity,  availability,  authentication,  and  non-repudiation  based  on  the  sensitivity 
of  the  information  handled.  To  ensure  the  security  of  Mission-Critical  Categories 
of  information,  not  only  must  vulnerability  analysis  by  the  developer  be 
performed,  but  the  evaluator  of  the  TOE  must  perform  independent  penetration 
testing  to  determine  that  the  TOE  is  resistant  to  penetration  attacks  performed  by 
attackers  possessing  a  moderate  attack  potential.  This  level  of  testing  is  required 
in  this  Protection  Profile  by  AVA_VEA.3.  Additionally,  in  order  to  ensure 
protection  of  Mission-Critical  information,  more  detailed  product  information  is 
required  from  the  vendor  to  facilitate  more  thorough  analysis.  This  requirement  is 
indicated  by  ADV_HED.2,  ADV_IMP.l,  and  ADV_EED.l  in  this  Protection 
Profile. 

19  Eor  all  Eederal  agencies,  including  Department  of  Defense  agencies,  for  the  use  of 
cryptographic  modules  in  the  protection  of  sensitive  but  unclassified  information, 
compliance  with  PIPS  PUB  140- 1  is  required'.  PIPS  PUB  140- 1  defines  security 
requirements  for  cryptographic  modules.  A  cryptographic  module  is  that  part  of  a 
system  or  application  that  provides  cryptographic  services  such  as  encryption, 
authentication,  or  electronic  signature  generation  and  verification.  Products  and 
systems  compliant  with  this  Protection  Profile  are  expected  to  utilize 
cryptographic  modules  for  remote  administration  compliant  with  this  PIPS  PUB. 


‘ .  See  FIPS-PUB  140-1  for  the  schedule  by  which  all  cryptographic  modules  used  by  Federal  agencies 
must  meet  the  provisions  of  this  standard. 
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3.1 


ASSUMPTIONS 


20 

A.PHYSEC 

A.MODEXP 

A.GENPUR 

A.PUBEIC 

A.NOEVIE 

A.SINGEN 

A.DIRECT 

A.NOREMO 

A.REMACC 

3.2 

21 

3.2.1 

22 

T.NOAUTH 


The  following  conditions  are  assumed  to  exist  in  the  operational  environment. 

The  TOE  is  physically  secure. 

The  threat  of  malicious  attacks  aimed  at  discovering  exploitable  vulnerabilities  is 
considered  moderate. 

There  are  no  general-purpose  computing  capabilities  (e.g.,  the  ability  to  execute 
arbitrary  code  or  applications)  and  storage  repository  capabilities  on  the  TOE. 

The  TOE  does  not  host  public  data. 

Authorized  administrators  are  non-hostile  and  follow  all  administrator  guidance; 
however,  they  are  capable  of  error. 

Information  can  not  flow  among  the  internal  and  external  networks  unless  it 
passes  through  the  TOE. 

Human  users  within  the  physically  secure  boundary  protecting  the  TOE  may 
attempt  to  access  the  TOE  from  some  direct  connection  (e.g.,  a  console  port)  if 
the  connection  is  part  of  the  TOE. 

Human  users  who  are  not  authorized  administrators  can  not  access  the  TOE 
remotely  from  the  internal  or  external  networks. 

Authorized  administrators  may  access  the  TOE  remotely  from  the  internal  and 
external  networks. 

THREATS 

The  following  threats  are  addressed  either  by  the  TOE  or  the  environment. 

THREATS  ADDRESSED  BY  THE  TOE 

The  threats  discussed  below  are  addressed  by  Protection  Profile-compliant  TOEs. 
The  threat  agents  are  either  unauthorized  persons  or  external  IT  entities  not 
authorized  to  use  the  TOE  itself. 

An  unauthorized  person  may  attempt  to  bypass  the  security  of  the  TOE  so  as  to 
access  and  use  security  functions  and/or  non-security  functions  provided  by  the 
TOE. 
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3.2.2 
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An  unauthorized  person  may  repeatedly  try  to  guess  authentication  data  in  order 
to  use  this  information  to  launch  attacks  on  the  TOE. 

An  unauthorized  person  may  use  valid  identification  and  authentication  data 
obtained  to  access  functions  provided  by  the  TOE. 

An  unauthorized  person  on  an  external  network  may  attempt  to  by-pass  the 
information  flow  control  policy  by  disguising  authentication  data  (e.g.,  spoofing 
the  source  address)  and  masquerading  as  a  legitimate  user  or  entity  on  an  internal 
network.. 

An  unauthorized  person  may  send  impermissible  information  through  the  TOE 
which  results  in  the  exploitation  of  resources  on  the  internal  network. 

Because  of  a  flaw  in  the  TOE  functioning,  an  unauthorized  person  may  gather 
residual  information  from  a  previous  information  flow  or  internal  TOE  data  by 
monitoring  the  padding  of  the  information  flows  from  the  TOE. 

An  unauthorized  person  or  unauthorized  external  IT  entity  may  be  able  to  view, 
modify,  and/or  delete  security  related  information  that  is  sent  between  a  remotely 
located  authorized  administrator  and  the  TOE. 

Persons  may  not  be  accountable  for  the  actions  that  they  conduct  because  the 
audit  records  are  not  reviewed,  thus  allowing  an  attacker  to  escape  detection. 

An  unauthorized  person  may  read,  modify,  or  destroy  security  critical  TOE 
configuration  data. 

An  unauthorized  person  may  cause  audit  records  to  be  lost  or  prevent  future 
records  from  being  recorded  by  taking  actions  to  exhaust  audit  storage  capacity, 
thus  masking  an  attackers  actions. 

A  skilled  attacker  with  moderate  attack  potential  may  attempt  to  bypass  the  TSE 
to  gain  access  to  the  TOE  or  the  assets  it  protects. 

THREAT  TO  BE  ADDRESSED  BY  OPERATING 
ENVIRONMENT 

The  threat  possibility  discussed  below  must  be  countered  by  procedural  measures 
and/or  administrative  methods. 

The  TOE  may  be  inadvertently  configured,  used,  and  administered  in  an  insecure 
manner  by  either  authorized  or  unauthorized  persons. 


7 


3.3 

24 


P.CRYPTO 


ORGANIZATIONAL  SECURITY  POLICIES 

Federal  agencies  are  required  to  protect  sensitive  but  unclassified  information 
with  cryptography.  Products  and  systems  compliant  with  this  Protection  Profile 
are  expected  to  utilize  cryptographic  modules  for  remote  administration  compliant 
with  FIPS  PUB  140-1  (level  1). 

Triple  DBS  encryption  (as  specified  in  FIPS  46-3  [3])  must  be  used  to  protect 
remote  administration  functions,  and  the  associated  cryptographic  module  must 
comply,  at  a  minimum,  with  FIPS  1 40- 1  (level  1). 
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SECURITY  OBJECTIVES 


4.1 
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INFORMATION  TECHNOLOGY  (IT)  SECURITY 
OBJECTIVES 

The  following  are  the  IT  security  objectives  for  the  TOE: 

The  TOE  must  uniquely  identify  and  authenticate  the  claimed  identity  of  all  users, 
before  granting  a  user  access  to  TOE  functions  or,  for  certain  specified  services, 
to  a  connected  network. 

The  TOE  must  prevent  the  reuse  of  authentication  data  for  users  attempting  to 
authenticate  to  the  TOE  from  a  connected  network. 

The  TOE  must  mediate  the  flow  of  all  information  between  clients  and  servers 
located  on  internal  and  external  networks  governed  by  the  TOE,  disallowing 
passage  of  non-conformant  protocols  and  ensuring  that  residual  information  from 
a  previous  information  flow  is  not  transmitted  in  any  way. 

Upon  initial  start-up  of  the  TOE  or  recovery  from  an  interruption  in  TOE  service, 
the  TOE  must  not  compromise  its  resources  or  those  of  any  connected  network. 

The  TOE  must  protect  the  confidentiality  of  its  dialogue  with  an  authorized 
administrator  through  encryption,  if  the  TOE  allows  administration  to  occur 
remotely  from  a  connected  network. 

The  TOE  must  protect  itself  against  attempts  by  unauthorized  users  to  bypass, 
deactivate,  or  tamper  with  TOE  security  functions. 

The  TOE  must  provide  a  means  to  record  a  readable  audit  trail  of  security-related 
events,  with  accurate  dates  and  times,  and  a  means  to  search  and  sort  the  audit 
trail  based  on  relevant  attributes. 

The  TOE  must  provide  user  accountability  for  information  flows  through  the  TOE 
and  for  authorized  administrator  use  of  security  functions  related  to  audit. 

The  TOE  must  provide  functionality  that  enables  an  authorized  administrator  to 
use  the  TOE  security  functions,  and  must  ensure  that  only  authorized 
administrators  are  able  to  access  such  functionality. 

The  TOE  must  provide  the  means  for  an  authorized  administrator  to  control  and 
limit  access  to  TOE  security  functions  by  an  authorized  external  IT  entity. 
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The  TOE  must  be  structurally  tested  and  shown  to  be  resistant  to  obvious 
vulnerabilities. 

Eor  a  detailed  mapping  between  threats  and  the  IT  security  objectives  listed 
above,  see  section  6.1  of  the  Rationale. 

SECURITY  OBJECTIVES  FOR  THE  ENVIRONMENT 

All  of  the  assumptions  stated  in  section  3.1  are  considered  to  be  security 
objectives  for  the  environment.  The  following  are  the  Protection  Profile  non-TT 
security  objectives  which  are  to  be  satisfied  without  imposing  technical 
requirements  on  the  TOE.  That  is,  they  will  not  require  the  implementation  of 
functions  in  the  TOE  hardware  and/or  software.  Thus,  they  will  be  satisfied 
largely  through  application  of  procedural  or  administrative  measures. 

The  TOE  is  physically  secure. 

The  threat  of  malicious  attacks  aimed  at  discovering  exploitable  vulnerabilities  is 
considered  moderate. 

There  are  no  general-purpose  computing  capabilities  (e.g.,  the  ability  to  execute 
arbitrary  code  or  applications)  and  storage  repository  capabilities  on  the  TOE. 

The  TOE  does  not  host  public  data. 

Authorized  administrators  are  non-hostile  and  follow  all  administrator  guidance; 
however,  they  are  capable  of  error. 

Information  can  not  flow  among  the  internal  and  external  networks  unless  it 
passes  through  the  TOE. 

Human  users  within  the  physically  secure  boundary  protecting  the  TOE  may 
attempt  to  access  the  TOE  from  some  direct  connection  (e.g.,  a  console  port)  if 
the  connection  is  part  of  the  TOE. 

Human  users  who  are  not  authorized  administrators  can  not  access  the  TOE 
remotely  from  the  internal  or  external  networks. 

Authorized  administrators  may  access  the  TOE  remotely  from  the  internal  and 
external  networks. 

The  TOE  must  be  delivered,  installed,  administered,  and  operated  in  a  manner 
that  maintains  security. 
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O.ADMTRA 

28 


Authorized  administrators  are  trained  as  to  establishment  and  maintenance  of 
security  policies  and  practices. 

For  a  detailed  mapping  between  threats,  assumptions,  and  the  non-IT  security 
objectives  listed  above  see  section  6.2  of  the  Rationale. 
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5 _ IT  SECURITY  REQUIREMENTS 

5.1  TOE  SECURITY  REQUIREMENTS 

29  This  Protection  Profile  provides  functional  and  assurance  requirements  that  must 
be  satisfied  by  a  Protection  Profile-compliant  TOE.  These  requirements  consist  of 
functional  components  from  Part  2  of  the  CC  and  an  Evaluation  Assurance  Eevel 
(EAE)  containing  assurance  components  from  Part  3  of  the  CC. 

5.1.1  TOE  SECURITY  REQUIREMENTS 

30  The  functional  security  requirements  for  this  Protection  Profile  consist  of  the 
following  components  from  Part  2  of  the  CC,  summarized  in  the  following  table. 


Functional  Components 

PMT_SMR.l 

Security  roles 

PIA_ATD.l 

User  attribute  definition 

PIA_UID.2 

User  identification  before  any  action 

PIA_APE.l 

Authentication  failure  handling 

PIA_UAU.5 

Multiple  authentication  mechanisms 

EDPJEC.l 

Subset  information  flow  control  (1) 

EDPJEC.l 

Subset  information  flow  control  (2) 

EDPJEE.l 

Simple  security  attributes  (1) 

EDPJEE.l 

Simple  security  attributes  (2) 

PMT_MSA.l 

Management  of  security  attributes  (1) 

PMT_MSA.l 

Management  of  security  attributes  (2) 

PMT_MSA.l 

Management  of  security  attributes  (3) 

PMT_MSA.l 

Management  of  security  attributes  (4) 

PMT_MSA.3 

Static  attribute  initialization 

PMT_MTD.l 

Management  of  TSE  data  (1) 

PMT_MTD.l 

Management  of  TSE  data  (2) 

PMT_MTD.2 

Management  of  limits  on  TSE  data 

PDP_RIP.l 

Subset  residual  information  protection 

PCS_COP.l 

Cryptographic  operation 

PPT_RVM.l 

Non-bypassability  of  the  TSP 

PPT_SEP.l 

TSE  domain  separation 

PPT_STM.l 

Reliable  time  stamps 

PAU_GEN.l 

Audit  data  generation 

PAU_SAR.l 

Audit  review 

PAU_SAR.3 

Selectable  audit  review 

PAU_STG.l 

Protected  audit  trail  storage 
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Functional  Components 

FAU_STG.4 

Prevention  of  audit  data  loss 

FMT_MOF.l 

Management  of  security  functions  behavior  (1) 

FMT_MOF.l 

Management  of  security  functions  behavior  (2) 

Table  5.1  -  Functional  Requirements 


31  The  statement  of  the  TOE  security  requirements  must  include  a  minimum  strength 
level  for  the  TOE  security  functions  realized  by  a  probablistic  or  permutational 
mechanism.  In  the  case  of  this  protection  profile,  this  minimum  level  shall  be 
SOE-medium.  Eor  a  rationale  for  this  selected  level,  see  section  6.3  of  the 
rationale. 

32  Specific  strength  of  function  metrics  are  defined  for  the  following  requirements: 

33  EIA_UAU.5  -  Strength  of  Eunction  shall  be  demonstrated  for  the  single-use 
authentication  mechanism  by  demonstrating  compliance  with  the  “Statistical 
random  number  generator  tests”  found  in  section  4.11.1  of  EIPS  PUB  140-1  [4] 
and  the  “Continuous  random  number  generator  test”  found  in  section  4.11.2  of 
PIPS  PUB  140- 1  [4].  Strength  of  function  shall  be  demonstrated  for  the  password 
authentication  mechanism  such  that  the  probability  that  authentication  data  can  be 
guessed  is  no  greater  than  one  in  two  to  the  fortieth  (2^40).  The  single-use  and 
password  authentication  mechanisms  must  demonstrate  SOE-medium,  as  defined 
in  Part  1  of  the  CC. 

34  The  following  paragraphs  are  intended  to  clarify  why  the  functional  components 
in  this  Protection  Profile  are  presented  in  the  order  outlined  in  Table  5.1. 
PMT_SMR.  1  is  the  first  component  because  it  defines  the  authorized 
administrator  role,  which  appears  in  a  number  of  the  components  that  follow. 

35  The  class  PIA  components  are  listed  after  PMT_SMR.  1 .  They  describe  the 
identification  and  authentication  policy  that  all  users,  both  human  users  and 
external  IT  entities,  must  abide  by  before  being  able  to  use  other  TOE  functions. 

36  The  order  of  the  class  PIA  components  was  chosen  on  the  following  basis.  Since 
users  are  already  defined  in  the  Terminology  section  on  page  vi,  the  Protection 
Profile  reader  is  introduced  in  component  PIA_ATD.l  to  their  security  attributes. 
The  next  component,  PIA_UID.2,  forces  users  to  identify  themselves  to  the  TOE 
using  the  user  security  attributes  of  component  PIA_ATD.l  before  further  actions 
take  place.  Then,  component  PIA_APE.  1  describes  what  results  if  the  user  fails  to 
authenticate  after  some  settable  number  of  attempts.  Eastly,  component 
PIA_UAU.5  discusses  when  authentication  mechanisms  must  be  used. 
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There  are  two  information  flow  control  SFPs,  and  they  are  defined  after  the  class 
FIA  components  in  FDP_IFC.l.  Then  the  policy  rules  which  must  be  enforced  as 
well  as  the  attributes  of  the  entities  defined  in  FDP_IFC.l  are  written  in 
FDP_IFF.l.  Next,  the  management  of  the  attributes  in  FDP_IFF.l  are  specified  in 
FMT_MSA.1(1),  FMT_MSA.1(2),  FMT_MSA.1(3)  and  FMT_MSA.1(4). 

Component  FMT_MSA.3,  which  FDP_IFF.l  depends  on,  follows.  As  part  of  the 
installation  and  start-up  of  the  TOE,  FMT_MSA.3  mandates  a  default  deny  policy 
which  permits  no  information  to  flow  through  the  TOE.  EMT_MTD.1(1), 
EMT_MTD.1(2),  and  EMT_MTD.2  define  the  management  of  TSE  data. 
EDP_RIP.l  is  listed  next,  ensuring  that  resources  are  cleared  before  being 
allocated  to  hold  packets  of  information  at  the  TOE. 

38  Component  ECS_COP.l  is  a  conditional  requirement.  If  the  developer  allows 
administration  from  a  remote  location  outside  the  physically  protected  TOE,  then 
evaluation  against  this  Protection  Profile  shall  require  the  TOE  to  meet  this 
component.  ECS_COP.l  defines  a  cryptographic  algorithm  as  well  as  the  key  size 
that  must  be  used.  The  cryptographic  module  must  be  EIPS  PUB  140-1  compliant 
for  the  reasons  stated  in  Section  3. 

39  Components  dealing  with  the  protection  of  trusted  security  functions  come  next. 
These  include  components  PPT_RVM.l  and  PPT_SEP.l. 

40  Since  PAU_GEN.  1  requires  recording  the  time  and  date  when  audit  events  occur, 
it  follows  the  PPT_STM.l  component  that  alerts  developers  that  an  accurate  time 
and  date  must  be  maintained  on  the  TOE.  The  class  EAU  requirements  follow  to 
define  the  audit  security  functions  which  must  be  supported  by  the  TOE. 
EAU_GEN.l  is  the  first  audit  component  listed  because  it  depicts  all  the  events 
that  must  be  audited,  including  all  the  information  which  must  be  recorded  in 
audit  records.  The  remainder  of  the  class  EAU  components  ensure  that  the  audit 
records  can  be  read  (component  EAU_SAR.l),  searched  and  sorted  (component 
EAU_SAR.3),  and  protected  from  modification  (EAU_STG.l).  Easily, 
EAU_STG.4  ensures  that  the  TOE  is  capable  of  preventing  auditable  actions,  not 
taken  by  an  authorized  administrator,  from  occurring  in  the  event  that  the  audit 
trail  becomes  full. 

41  The  last  component  in  the  profile  is  EMT_MOE.  1 .  It  appears  last  because  it  lists 
all  the  functions  to  be  provided  by  the  TOE  for  use  only  by  the  authorized 
administrator.  Almost  all  of  these  functions  are  based  on  components  which 
precede  it.  Thus  it  is  listed  last. 
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FMT_SMR.l  Security  roles 

42  FMT_SMR.1.1  -  The  TSF  shall  maintain  the  role  [authorized  administrator]. 

43  FMT_SMR.1.2  -  The  TSF  shall  be  able  to  associate  human  users  with  the 

authorized  administrator  role. 

FIA_ATD.l  User  attribute  definition 

44  FIA_ATD.1.1  -  The  TSF  shall  maintain  the  following  list  of  security  attributes 
belonging  to  individual  users: 

a)  [identity; 

b)  association  of  a  human  user  with  the  authorized  administrator  role; 

c)  any  other  user  security  attributes  [to  be  determined  by  the  Security  Target 
writer(s)}]. 

FIA_UID.2  User  identification  before  any  action 

45  FIA_UID.2.1  -  The  TSF  shall  require  each  user  to  identify  itself  before  allowing 
any  other  TSF-mediated  actions  on  behalf  of  that  user. 

FIA_AFL.  1  Authentication  failure  handling 

46  FIA_AFL.1.1  -  The  TSF  shall  detect  when  [a  non-zero  number  determined  by  the 
authorized  administrator]  of  unsuccessful  authentication  attempts  occur  related  to 
[authorized  TOE  administrator  access  or  authorized  TOE  IT  entity  access]. 

47  EIA_AEE.1.2  -  When  the  defined  number  of  unsuccessful  authentication  attempts 
has  been  met  or  surpassed,  the  TSE  shall  [prevent  the  offending  user  from 
successfully  authenticating  until  an  authorized  administrator  takes  some  action  to 
make  authentication  possible  for  the  user  in  question.] 
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FIA_UAU.5  Multiple  authentication  mechanisms 

48  FIA_UAU.5.1  -  The  TSF  shall  provide  [password  and  single-use  authentication 
mechanisms]  to  support  user  authentication. 

49  FIA_UAU.5.2  -  The  TSF  shall  authenticate  any  user's  claimed  identity  according 
to  the  [following  multiple  authentication  mechanism  rules: 

a)  single-use  authentication  mechanism  shall  be  used  for  authorized 
administrators  to  access  the  TOE  remotely  such  that  successful 
authentication  must  be  achieved  before  allowing  any  other  TSF- 
mediated  actions  on  behalf  of  that  authorized  administrator; 

b)  single-use  authentication  mechanism  shall  be  used  for  authorized 
external  IT  entities  accessing  the  TOE  such  that  successful 
authentication  must  be  achieved  before  allowing  any  other  TSE- 
mediated  actions  on  behalf  of  that  authorized  external  IT  entity; 

c)  single-use  authentication  mechanism  shall  be  used  for  human  users 
sending  or  receiving  information  through  the  TOE  using  ETP  or  Telnet 
such  that  successful  authentication  must  be  achieved  before  allowing 
any  other  TSE-mediated  actions  on  behalf  of  that  human  user; 

d)  reusable  password  mechanism  shall  be  used  for  authorized 
administrators  to  access  the  TOE  via  a  directly  connected  terminal 
such  that  successful  authentication  must  be  achieved  before  allowing 
any  other  TSE-mediated  actions  on  behalf  of  that  authorized 
administrator] . 

50  Application  Note:  TOEs  that  do  not  provide  capabilities  for  authorized 
administrators  to  access  the  TOE  remotely  from  either  an  internal  or  external 
network  (i.e.,  for  remote  administration),  or  for  authorized  external  IT  entities  do 
not  have  to  make  such  functionality  available  in  order  to  satisfy  this  requirement. 
The  intent  of  this  requirement  is  not  to  require  developers  to  provide  all  such 
capabilities  and  their  associated  authentication  mechanisms.  The  requirement 
applies  to  those  developers  that  do  incorporate  such  functionality  and  intend  for  it 
to  be  evaluated. 
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51 


Requirements  Overview:  This  Protection  Profile  consists  of  multiple  information 
flow  control  Security  Function  Policies  (SFPs).  The  CC  allows  multiple  policies 
to  exist,  each  having  a  unique  name.  This  is  accomplished  by  iterating  FDP_IFC.l 
for  each  of  the  two  named  information  flow  control  policies.  The  first  policy 
identified  is  called  the  UNAUTHENTICATED  SEP.  The  subjects  under  control 
of  this  policy  are  external  IT  entities  on  an  internal  or  external  network  sending 
information  through  the  TOE  to  other  external  IT  entities.  The  second  policy 
identified  is  called  the  AUTHENTICATED  SEP.  The  subjects  under  control  of 
this  policy  are  human  users  on  an  internal  or  external  network  who  must  be 
authenticated  at  the  TOE  before  using  the  services  in  EIA_UAU.5.  The 
information  flowing  between  subjects  in  both  policies  is  traffic  with  attributes, 
defined  in  EDP_IEE.1.1,  including  source  and  destination  addresses.  The  rules 
that  define  each  information  flow  control  SEP  are  found  in  PDP_IPP.1.2. 
Component  EDPJEE.l  is  iterated  twice  to  correspond  to  each  of  the  two 
iterations  of  EDPJEC .  1 . 

EDPJEC.  1  Subset  information  flow  control  (1) 

52  EDPJEC.  1 . 1  -  The  TSE  shall  enforce  the  [UNAUTHENTICATED  SEP]  on: 

a)  [subjects:  unauthenticated  external  IT  entities  that  send  and  receive 
information  through  the  TOE  to  one  another; 

b)  information:  traffic  sent  through  the  TOE  from  one  subject  to  another;  and 

c)  operation:  pass  information]. 

EDP_IEC.  1  Subset  information  flow  control  (2) 

53  EDPJEC.  1 . 1  -  The  TSE  shall  enforce  the  [AUTHENTICATED  SEP]  on: 

a)  [subjects:  a  human  user  or  external  IT  entity  that  sends  and  receives  ETP 
and  Telnet  information  through  the  TOE  to  one  another,  only  after  the 
human  user  initiating  the  information  flow  has  authenticated  at  the  TOE 
per  EIA_UAU.5; 

b)  information:  ETP  and  Telnet  traffic  sent  through  the  TOE  from  one 
subject  to  another;  and 

c)  operation:  initiate  service  and  pass  information]. 
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FDP_IFF.l  Simple  security  attributes  (1)^ 

54  FDP_IFF.  1 . 1  -  The  TSF  shall  enforce  the  [UNAUTHENTICATED  SEP]  based  on 

at  least  the  following  types  of  subject  and  information  security  attributes: 

a)  [subject  security  attributes: 

•  presumed  address;  and 

•  other  subject  security  attributes  [to  be  determined  by  the  Security 
Target  writer(s) ) ; 

b)  information  security  attributes: 

•  presumed  address  of  source  subject; 

•  presumed  address  of  destination  subject; 

•  transport  layer  protocol; 

•  TOE  interface  on  which  traffic  arrives  and  departs; 

•  service;  and 

•  other  information  security  attributes  [to  be  determined  by  the 
Security  Target  writer(s))]. 


The  complete  set  of  functional  elements  of  a  component  must  be  selected  for  inclusion  in  a  PP.  However, 
since  the  following  functional  elements  from  the  FDP_IFF.l  (1)  component  do  not  add  anything  significant 
to  the  PP,  they  have  been  moved  here  to  allow  for  a  clearer,  smoother  flowing  presentation  of 
FDP_IFF.1(1). 

FDP_IFF.L3  -  The  TSF  shall  enforce  the  [none], 

FDP_IFF.L4  -  The  TSF  shall  provide  the  following  [none], 

FDP_IFF.L5  -  The  TSF  shall  explicitly  authorize  an  information  flow  based  on  the 

following  rules:  [none]. 


18 


55 


FDP_IFF.1.2  -  The  TSF  shall  permit  an  information  flow  between  a  controlled 
subject  and  another  controlled  subject  via  a  controlled  operation  if  the  following 
rules  hold: 


a)  [Subjects  on  an  internal  network  can  cause  information  to  flow  through 

the  TOE  to  another  connected  network  if: 

•  the  human  user  initiating  the  information  flow  authenticates  according 
to  FIA_UAU.5; 

•  all  the  information  security  attribute  values  are  unambiguously 
permitted  by  the  information  flow  security  policy  rules,  where  such 
rules  may  be  composed  from  all  possible  combinations  of  the  values  of 
the  information  flow  security  attributes,  created  by  the  authorized 
administrator; 

•  the  presumed  address  of  the  source  subject,  in  the  information, 
translates  to  an  internal  network  address;  and 

•  the  presumed  address  of  the  destination  subject,  in  the  information, 
translates  to  an  address  on  the  other  connected  network. 

b)  Subjects  on  the  external  network  can  cause  information  to  flow  through 

the  TOE  to  another  connected  network  if: 

•  the  human  user  initiating  the  information  flow  authenticates  according 
to  EIA_UAU.5; 

•  all  the  information  security  attribute  values  are  unambiguously 
permitted  by  the  information  flow  security  policy  rules,  where  such 
rules  may  be  composed  from  all  possible  combinations  of  the  values  of 
the  information  flow  security  attributes,  created  by  the  authorized 
administrator; 

•  the  presumed  address  of  the  source  subject,  in  the  information, 
translates  to  an  external  network  address;  and 

•  the  presumed  address  of  the  destination  subject,  in  the  information, 
translates  to  an  address  on  the  other  connected  network.] 
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56  FDP_IFF.1.6  -  The  TSF  shall  explicitly  deny  an  information  flow  based  on  the 
following  rules: 

a)  [The  TOE  shall  reject  requests  for  access  or  services  where  the 
information  arrives  on  an  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  an  internal 
network; 

b)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  an  internal  TOE  interface,  and  the  presumed  address  of  the 
source  subject  is  an  external  IT  entity  on  the  external  network; 

c)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  either  an  internal  or  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  a  broadcast 
network; 

d)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  either  an  internal  or  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  the  loopback 
network; 

e)  The  TOE  shall  reject  requests  in  which  the  subject  specifies  the  route  in 
which  information  shall  flow  en  route  to  the  receiving  subject;  and 

f)  Eor  application  protocols  supported  by  the  TOE  (e.g.,  DNS,  HTTP, 
SMTP,  and  POPS),  the  TOE  shall  deny  any  access  or  service  requests  that 
do  not  conform  to  its  associated  published  protocol  specification  (e.g., 
REC).  This  shall  be  accomplished  through  protocol  filtering  proxies  that 
are  designed  for  that  purpose. 

57  Application  Note:  Rule  f)  applies  when  an  application-level  proxy  is  provided  for 
the  following  protocols:  DNS,  HTTP,  SMTP,  and  POPS. 
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FDP_IFF.l  Simple  security  attributes  (2)^ 

58  FDPJFF.l.l  -  The  TSF  shall  enforce  the  [AUTHENTICATED  SEP]  based  on  at 

least  the  following  types  of  subject  and  information  security  attributes: 

a)  [subject  security  attributes: 

•  presumed  address;  and 

•  other  subject  security  attributes  [to  be  determined  by  the  Security 
Target  writer(s)}; 

b)  information  security  attributes: 

•  user  identity; 

•  presumed  address  of  source  subject; 

•  presumed  address  of  destination  subject; 

•  transport  layer  protocol; 

•  TOE  interface  on  which  traffic  arrives  and  departs; 

•  service  (i.e.,  ETP  and  Telnet); 

•  security-relevant  service  command;  and 

•  other  information  security  attributes  [to  be  determined  by  the  Security 
Target  writer(s)}] 


The  complete  set  of  functional  elements  of  a  component  must  be  selected  for  inclusion  in  a  PP.  However, 
since  the  following  functional  elements  from  the  FDP_IFF-1  (2)  component  do  not  add  anything  significant 
to  the  PP,  they  have  been  moved  here  to  allow  for  a  clearer,  smoother  flowing  presentation  of  FDP_IFF.l 
(2). 

FDP_IFF.1.3  -  The  TSF  shall  enforce  the  [none] . 

FDP_IFF.L4  -  The  TSF  shall  provide  the  following  [none] . 

FDP_IFF.L5  -  The  TSF  shall  explicitly  authorize  an  information  flow  based  on  the 

following  rules:  [none]. 
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59 


FDP_IFF.1.2  -  The  TSF  shall  permit  an  information  flow  between  a  controlled 
subject  and  another  controlled  subject  via  a  controlled  operation  if  the  following 
rules  hold: 


a)  [Subjects  on  an  internal  network  can  cause  information  to  flow  through 

the  TOE  to  another  connected  network  if: 

•  all  the  information  security  attribute  values  are  unambiguously 
permitted  by  the  information  flow  security  policy  rules,  where  such 
rules  may  be  composed  from  all  possible  combinations  of  the  values  of 
the  information  flow  security  attributes,  created  by  the  authorized 
administrator; 

•  the  presumed  address  of  the  source  subject,  in  the  information, 
translates  to  an  internal  network  address;  and 

•  the  presumed  address  of  the  destination  subject,  in  the  information, 
translates  to  an  address  on  the  other  connected  network. 

b)  Subjects  on  the  external  network  can  cause  information  to  flow  through 

the  TOE  to  another  connected  network  if: 

•  all  the  information  security  attribute  values  are  unambiguously 
permitted  by  the  information  flow  security  policy  rules,  where  such 
rules  may  be  composed  from  all  possible  combinations  of  the  values  of 
the  information  flow  security  attributes,  created  by  the  authorized 
administrator; 

•  the  presumed  address  of  the  source  subject,  in  the  information, 
translates  to  an  external  network  address;  and 

•  the  presumed  address  of  the  destination  subject,  in  the  information, 
translates  to  an  address  on  the  other  connected  network.] 
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60  FDP_IFF.1.6  -  The  TSF  shall  explicitly  deny  an  information  flow  based  on  the 
following  rules: 

a)  [The  TOE  shall  reject  requests  for  access  or  services  where  the 
information  arrives  on  an  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  an  internal 
network; 

b)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  an  internal  TOE  interface,  and  the  presumed  address  of  the 
source  subject  is  an  external  IT  entity  on  the  external  network; 

c)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  either  an  internal  or  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  a  broadcast 
network; 

d)  The  TOE  shall  reject  requests  for  access  or  services  where  the  information 
arrives  on  either  an  internal  or  external  TOE  interface,  and  the  presumed 
address  of  the  source  subject  is  an  external  IT  entity  on  the  loopback 
network 

e)  The  TOE  shall  reject  requests  in  which  the  subject  specifies  the  route  in 
which  information  shall  flow  en  route  to  the  receiving  subject;  and 

f)  The  TOE  shall  reject  Telnet  or  ETP  command  requests  that  do  not 
conform  to  generally  accepted  published  protocol  definitions  (e.g.,  RECs). 
This  must  be  accomplished  through  protocol  filtering  proxies  designed  for 
that  purpose. 

61  Application  Note:  The  TOE  can  make  no  claim  as  to  the  real  address  of  any 
source  or  destination  subject,  therefore  the  TOE  can  only  suppose  that  these 
addresses  are  accurate.  Therefore,  a  “presumed  address”  is  used  to  identify  source 
and  destination  addresses.  A  “service”,  listed  in  EDP_IEE.  1.1(b),  could  be 
identified,  for  example,  by  a  source  port  number  and/or  destination  port  number. 
A  “service  command”,  also  mentioned  EDP_IEE.  1.1(b),  could  be  identified,  for 
example,  in  the  case  of  the  Eile  Transport  Protocol  (ETP)  service  as  an  ETP 
STOR  or  ETP  RETR. 
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FMT_MS  A.  1  Management  of  security  attributes  (1) 

62  FMT_MSA.  1 . 1  ( 1)  -  The  TSF  shall  enforce  the  [UNAUTHENTICATED_SFP]  to 
restrict  the  ability  to  [delete  attributes  from  a  rule,  modify  attributes  in  a  rule,  add 
attributes  to  a  rule]  the  security  attributes  [listed  in  section  EDP_IEE  1.1(1)]  to  [the 
authorized  administrator] . 

PMT_MSA.l  Management  of  security  attributes  (2) 

63  PMT_MSA.1.1(2)  -  The  TSE  shall  enforce  the  [AUTHENTIC ATED_SEP]  to 
restrict  the  ability  to  [delete  attributes  from  a  rule,  modify  attributes  in  a  rule,  add 
attributes  to  a  rule]  the  security  attributes  [listed  in  section  EDP_IEE  1.1(2)]  to  [the 
authorized  administrator] . 

EMT_MSA.l  Management  of  security  attributes  (3) 

64  EMT_MSA.1.1(3)  -  The  TSE  shall  enforce  the  [UNAUTHENTICATED_SEP]  to 
restrict  the  ability  to  delete  and  [create]  the  security  attributes  [information  flow 
rules  described  in  EDP_IEE.1(1)]  to  [the  authorized  administrator]. 

EMT_MSA.l  Management  of  security  attributes  (4) 

65  EMT_MSA.1.1(4)  -  The  TSE  shall  enforce  the  [ AUTHENTIC ATED_SEP]  to 
restrict  the  ability  to  delete  and  [create]  the  security  attributes  [information  flow 
rules  described  in  EDP_IEE.1(2)]  to  [the  authorized  administrator]. 

EMT_MSA.3  Static  attribute  initialization 

66  EMT_MSA.3.1  -  The  TSE  shall  enforce  the  [UNAUTHENTICATED_SEP  and 
AUTHENTICATED_SEP]  to  provide  restrictive  default  values  for  information 
flow  security  attributes  that  are  used  to  enforce  the  SEP. 

67  PMT_MSA.3.2  -  The  TSE  shall  allow  [the  authorized  administrator]  to  specify 
alternative  initial  values  to  override  the  default  values  when  an  object  or 
information  is  created. 

68  Application  Note:  The  default  values  for  the  information  flow  control  security 
attributes  appearing  in  EDP_IEE.l  (1)  and  EDP_IEE.l  (2)  are  intended  to  be 
restrictive  in  the  sense  that  both  inbound  and  outbound  information  is  denied  by 
the  TOE  until  the  default  values  are  modified  by  an  authorized  administrator. 
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FMT_MTD.  1  Management  of  TSF  data  ( 1 ) 

69  FMT_MTD. 1.1(1)  -  The  TSF  shall  restrict  the  ability  to  query,  modify,  delete, 
[and  assign]  the  [user  attributes  defined  in  FIA_ATD.1.1]  to  [the  authorized 
administrator]. 

FMT_MTD.  1  Management  of  TSF  data  (2) 

70  FMT_MTD.  1.1(2)  -  The  TSF  shall  restrict  the  ability  to  [set]  the  [time  and  date 
used  to  form  the  timestamps  in  FPT_STM.1.1]  to  [the  authorized  administrator]. 

FMT_MTD.2  Management  of  limits  on  TSF  data 

71  FMT_MTD.2.1  -  The  TSF  shall  restrict  the  specification  of  the  limits  for  [the 
number  of  authentication  failures]  to  [the  authorized  administrator]. 

72  FMT_MTD.2.2  -  The  TSF  shall  take  the  following  actions,  if  the  TSF  data  are  at, 
or  exceed,  the  indicated  limits:  [actions  specified  in  FIA_AFL.1.2]. 

FDP_RIP.  1  Subset  residual  information  protection 

73  FDP_RIP.1.1  -  The  TSF  shall  ensure  that  any  previous  information  content  of  a 
resource  is  made  unavailable  upon  the  allocation  of  the  resource  to  [all  objects]. 

74  Application  Note:  If,  for  example,  the  TOE  pads  information  with  bits  in  order  to 
properly  prepare  the  information  before  sending  it  out  an  interface,  these  bits 
would  be  considered  a  “resource”.  The  intent  of  the  requirement  is  that  these  bits 
shall  not  contain  the  remains  of  information  that  had  previously  passed  through 
the  TOE.  The  requirement  is  met  by  overwriting  or  clearing  resources  (e.g. 
packets)  before  making  them  available  for  use. 

ECS_COP.l  Cryptographic  operation 

75  ECS_COP.l.l  -  The  TSE  shall  perform  [encryption  of  remote  authorized 
administrator  sessions]  in  accordance  with  a  specified  cryptographic  algorithm: 
[Triple  Data  Encryption  Standard  (DES)  as  specified  in  EIPS  PUB  46-3  and 
implementing  any  mode  of  operation  specified  in  PIPS  PUB  46-3  with  Keying 
Option  1  (Kl,  K2,  K3  are  independent  keys)]  and  cryptographic  key  sizes  [that 
are  192  binary  digits  in  length]  that  meet  the  following:  [PIPS  PUB  46-3  with 
Keying  Option  1  and  PIPS  PUB  140-1  (Eevel  1)]. 

76  Application  Note:  This  requirement  is  applicable  only  if  the  TOE  includes  the 
capability  for  the  authorized  administrator  to  perform  security  functions  remotely 
from  a  connected  network.  In  this  case.  Triple  DES  encryption  must  protect  the 
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communications  between  the  authorized  administrator  and  the  TOE,  and  the 
assoeiated  eryptographie  module(s)  must  eomply  at  a  minimum  with  FIPS  PUB 
140-1  Level  1.  The  intent  of  this  requirement  is  not  for  the  evaluator  to  perform  a 
FIPS  PUB  140-1  evaluation;  rather,  the  evaluator  will  cheek  for  a  certificate, 
verifying  that  the  module  did  complete  a  FIPS  PUB  140-1  evaluation. 

FPT_RVM.  1  Non-bypassability  of  the  TSP 

77  FPT_RVM.1.1  -  The  TSF  shall  ensure  that  TSP  enforeement  funetions  are 
invoked  and  succeed  before  each  function  within  the  TSC  is  allowed  to  proeeed. 

FPT_SEP.  1  TSF  domain  separation 

78  FPT_SEP.1.1  -  The  TSF  shall  maintain  a  seeurity  domain  for  its  own  exeeution 
that  proteets  it  from  interferenee  and  tampering  by  untrusted  subjeets. 

79  FPT_SEP.1.2  -  The  TSF  shall  enforce  separation  between  the  security  domains  of 
subjects  in  the  TSC. 

FPT_STM.  1  Reliable  time  stamps 

80  FPT_STM.1.1  -  The  TSF  shall  be  able  to  provide  reliable  time  stamps  for  its  own 
use. 

81  Application  Note:  The  word  “reliable”  in  the  above  requirement  means  that  the 
order  of  the  oeeurrenee  of  auditable  events  is  preserved.  Reliable  time  stamps, 
whieh  inelude  both  date  and  time,  are  espeeially  important  for  TOEs  eomprised  of 
greater  than  one  component. 

FAU_GEN.  1  Audit  data  generation 

82  FAU_GEN.1.1  -  The  TSF  shall  be  able  to  generate  an  audit  reeord  of  the 
following  auditable  events: 

a)  Start-up  and  shutdown  of  the  audit  functions; 

b)  All  auditable  events  for  the  not  specified  level  of  audit;  and 

c)  [the  events  in  Table  5.2]. 
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83 


FAU_GEN.1.2  -  The  TSF  shall  record  within  each  audit  record  at  least  the 
following  information: 


a)  Date  and  time  of  the  event,  type  of  event,  subject  identity,  outcome 
(success  or  failure)  of  the  event;  and 

b)  For  each  audit  event  type,  based  on  the  auditable  event  definitions  of  the 
functional  components  included  in  the  PP/ST,  [information  specified  in 
column  three  of  Table  5.2]. 


Functional 

Component 

Auditable  Event 

Additional  Audit  Record 
Contents 

FMT_SMR.l 

Modifications  to  the  group 
of  users  that  are  part  of 

the  authorized 
administrator  role. 

The  identity  of  the  authorized 
administrator  performing  the 
modification  and  the  user 
identity  being  associated  with 
the  authorized  administrator  role. 

Unsuccessful  attempts  to 
authenticate  the 
authorized  administrator 
role. 

The  user  identity  and  the  role. 

FIA_UID.2 

All  use  of  the  user 
identification  mechanism. 

The  user  identities  provided  to 
the  TOE. 

FIA_UAU.l 

Any  use  of  the 
authentication  mechanism. 

The  user  identities  provided  to 
the  TOE. 

FIA_UAU.5 

The  final  decision  on 
authentication. 

The  user  identity  and  the  success 
or  failure  of  the  authentication. 

FIA_AFF.l 

The  reaching  of  the 
threshold  for  unsuccessful 
authentication  attempts 
and  the  subsequent 

restoration  by  the 
authorized 
administrator  of  the 
users  capability  to 
authenticate. 

The  identity  of  the  offending 
user  and  the  authorized 
administrator. 

FDPJFF.l 

All  decisions  on  requests 
for  information  flow. 

The  presumed  addresses  of  the 
source  and  destination  subject. 

FCS_COP.l 

Success  and  failure,  and 

The  identity  of  the  external  IT 
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Functional 

Component 

Auditable  Event 

Additional  Audit  Record 
Contents 

the  type  of  cryptographic 
operation. 

entity  attempting  to  perform  the 
cryptographic  operation. 

EPT_STM.l 

Changes  to  the  time. 

The  identity  of  the  authorized 
administrator  performing  the 
operation. 

EMT_MOE.l 

Use  of  the  functions  listed 
in  this  requirement 
pertaining  to  audit. 

The  identity  of  the  authorized 
administrator  performing  the 
operation. 

Table  5.2  -  Auditable  Events 


FAU  SAR.  1  Audit  review 
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FAU_SAR.1.1  -  The  TSF  shall  provide  [an  authorized  administrator]  with  the 
capability  to  read  [all  audit  trail  data]  from  the  audit  records. 


85  FAU_SAR.1.2  -  The  TSF  shall  provide  the  audit  records  in  a  manner  suitable  for 

the  user  to  interpret  the  information. 

FAU  SAR.  3  Selectable  audit  review 
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FAU_SAR.3.1  -  The  TSF  shall  provide  the  ability  to  perform  searches  and 
sorting  of  audit  data  based  on: 


a)  [user  identity; 

b)  presumed  subject  address; 

c)  ranges  of  dates; 

d)  ranges  of  times;  and 

e)  ranges  of  addresses]. 

87  Application  Note:  The  Security  Target  writer(s)  is  expected  to  describe,  as  part  of 

their  “TOE  Summary  Specification”  section,  the  capabilities  of  the  tool(s)  used  by 
the  TOE  to  perform  these  searches  and  sorts. 
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FAU_STG.l  Protected  audit  trail  storage 

88  FAU_STG.1.1  -  The  TSF  shall  protect  the  stored  audit  records  from  unauthorized 

deletion. 
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FAU_STG.1.2  -  The  TSF  shall  be  able  to  prevent  modifications  to  the  audit 
records. 


FAU_STG.4  Prevention  of  audit  data  loss 

90  FAU_STG.4.  -  The  TSF  shall  prevent  auditable  events,  except  those  taken  by  the 

authorized  administrator  and  [shall  limit  the  number  of  audit  records  lost]  if  the 
audit  trail  is  full. 


91  Application  Note:  The  Security  Target  writer(s)  is  expected  to  provide,  as  part  of 
their  “Security  requirements  rationale”  section,  an  analysis  of  the  maximum 
amount  of  audit  data  that  can  be  expected  to  be  lost  in  the  event  of  audit  storage 
failure,  exhaustion,  and/or  attack. 

FMT_MOF.l  Management  of  security  functions  behavior  (1) 

92  FMT_MOF.  1.1(1)  -  The  TSF  shall  restrict  the  ability  to  enable,  disable  the 
functions: 


a)  [operation  of  the  TOE;  and 

b)  multiple  use  authentication  as  described  in  FIA_UAU.5]  to  [an  authorized 
administrator] . 

93  Application  Note:  By  “Operation  of  the  TOE”  in  a)  above,  we  mean  having  the 
TOE  start  up  (enable  operation)  and  shut  down  (disable  operation).  By  “multiple 
use”  in  b)  above,  we  mean  the  management  of  password  and  single-use 
authentication  mechanisms. 

EMT_MOE.l  Management  of  security  functions  behavior  (2) 

94  EMT_MOE.l.l(2)  -  The  TSE  shall  restrict  the  ability  to  enable,  disable, 
determine  and  modify  the  behaviour  of  the  functions: 

a)  [audit  trail  management; 

b)  backup  and  restore  for  TSE  data,  information  flow  rules,  and  audit  trail 
data;  and 
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c)  communication  of  authorized  external  IT  entities  with  the  TOE]  to  [an 
authorized  administrator] . 

95  Application  Note:  Determine  and  modify  the  behavior  of  element  c 

(communication  of  authorized  external  IT  entities  with  the  TOE)  is  intended  to 
cover  functionality  such  as  providing  a  range  of  addresses  from  which  the 
authorized  external  entity  can  connect. 

5.1.2  TOE  SECURITY  ASSURANCE  REQUIREMENTS 

96  The  assurance  security  requirements  for  this  Protection  Profile,  taken  from  Part  3 
of  the  CC,  compose  EAE2  Augmented.  These  assurance  components  are 
summarized  in  the  following  table. 


Assurance  Class 

Assurance  Components 

Configuration 

management 

ACM_CAP.2 

Configuration  items 

Delivery  and  operation 

ADO_DEE.l 

Delivery  procedures 

ADOJGS.l 

Installation,  generation,  and  start-up  procedures 

Development 

ADV_PSP.l 

Informal  functional  specification 

ADV_HED.2 

Security  enforcing  high-level  design 

ADVJMP.l 

Implementation  representation 

ADV_EED.l 

Eow-level  design 

ADV_RCR.l 

Informal  correspondence  demonstration 

Guidance  documents 

AGD_ADM.l 

Administrator  guidance 

AGD_USR.l 

User  guidance 

AEC_TAT.l 

Tools  and  techniques 

Tests 

ATE_COV.l 

Evidence  of  coverage 

ATE_PUN.l 

Eunctional  testing 

ATE_IND.2 

Independent  testing  -  sample 

Vulnerability  assessment 

AVA_SOP.l 

Strength  of  TOE  security  function  evaluation 

AVA_VEA.3  Moderately  resistant 

Table  5.3  -  Assurance  Requirements:  EAL2  Augmented 
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ACM_CAP.2  Configuration  items 

Developer  action  elements: 

97  ACM_CAP.2.1D  -  The  developer  shall  provide  a  reference  for  the  TOE. 

98  ACM_CAP.2.2D  -  The  developer  shall  use  a  CM  system. 

99  ACM_CAP.2.3D  -  The  developer  shall  provide  CM  documentation. 

Content  and  presentation  of  evidence  elements: 

100  ACM_CAP.2.1C  -  The  reference  for  the  TOE  shall  be  unique  to  each  version  of 
the  TOE. 


101  ACM_CAP.2.2C  -  The  TOE  shall  be  labeled  with  its  reference. 

102  ACM_CAP.2.3C  -  The  CM  documentation  shall  include  a  configuration  list. 

103  ACM_CAP.2.4C  -  The  configuration  list  shall  describe  the  configuration  items 
that  comprise  the  TOE. 

104  ACM_CAP.2.5C  -  The  CM  documentation  shall  describe  the  method  used  to 
uniquely  identify  the  configuration  items. 

105  ACM_CAP.2.6C  -  The  CM  system  shall  uniquely  identify  all  configuration  items. 
Evaluator  action  elements: 

106  ACM_CAP.2.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

ADO_DEE.  1  Delivery  procedures 

Developer  action  elements: 

107  ADO_DEE.l.lD  -  The  developer  shall  document  procedures  for  delivery  of  the 
TOE  or  parts  of  it  to  the  user. 

108  ADO_DEE.1.2D  -  The  developer  shall  use  the  delivery  procedures. 
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Content  and  presentation  of  evidence  elements: 

109  AD0_DEL.1.1C  -  The  delivery  documentation  shall  describe  all  procedures  that 

are  necessary  to  maintain  security  when  distributing  versions  of  the  TOE  to  a 
user’s  site. 

no  AD0_DEE.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 

meets  all  requirements  for  content  and  presentation  of  evidence. 

111  ADO_IGS.l  Installation,  generation,  and  start-up  procedures 
Developer  action  elements: 

112  AD0_IGS.1.1D  -  The  developer  shall  document  procedures  necessary  for  the 
secure  installation,  generation,  and  start-up  of  the  TOE. 

Content  and  presentation  of  evidence  elements: 

113  AD0_IGS.1.1C  -  The  documentation  shall  describe  the  steps  necessary  for  secure 
installation,  generation,  and  start-up  of  the  TOE.  Evaluator  action  elements: 

Evaluator  action  elements: 

1 14  ADO_IGS. TIE  -  The  evaluator  shall  confirm  that  the  information  provided  meets 
all  requirements  for  content  and  presentation  of  evidence. 

115  ADO_IGS.1.2E  -  The  evaluator  shall  determine  that  the  installation,  generation, 
and  start-up  procedures  result  in  a  secure  configuration. 

ADV_ESP.l  Informal  functional  specification 

Developer  action  elements: 

116  ADV_ESP.  1 .  ID  -  The  developer  shall  provide  a  functional  specification. 

Content  and  presentation  of  evidence  elements: 

117  ADV_PSP.1.1C  -  The  functional  specification  shall  describe  the  TSE  and  its 
external  interfaces  using  an  informal  style. 

118  ADV_ESP.1.2C  -  The  functional  specification  shall  be  internally  consistent. 

119  ADV_ESP.1.3C  -  The  functional  specification  shall  describe  the  purpose  and 
method  of  use  of  all  external  TSE  interfaces,  providing  details  of  effects. 
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exceptions  and  error  messages,  as  appropriate. 

120  ADV_FSP.1.4C  -  The  functional  specification  shall  completely  represent  the  TSF. 
Evaluator  action  elements: 

121  ADV_FSP. LIE  -  The  evaluator  shall  confirm  that  the  information  provided  meets 
all  requirements  for  content  and  presentation  of  evidence. 

122  ADV_ESP.1.2E  -  The  evaluator  shall  determine  that  the  functional  specification  is 
an  accurate  and  complete  instantiation  of  the  TOE  security  functional 
requirements. 

123  Application  Note:  This  requirement  can  potentially  be  met  by  a  combination  of 
documents  provided  by  the  developer,  including  the  Security  Target  and  external 
interface  specification. 

ADV_HED.2  Security  enforcing  high-level  design 
Developer  action  elements: 

124  ADV_HED.2.1D  -  The  developer  shall  provide  the  high-level  design  of  the  TSE. 
Content  and  presentation  of  evidence  elements: 

125  ADV_HED.2.1C  -  The  presentation  of  the  high-level  design  shall  be  informal. 

126  ADV_HED.2.2C  -  The  high-level  design  shall  be  internally  consistent. 

127  ADV_HED.2.3C  -  The  high-level  design  shall  describe  the  structure  of  the  TSE  in 
terms  of  subsystems. 

128  ADV_HED.2.4C  -  The  high-level  design  shall  describe  the  security  functionality 
provided  by  each  subsystem  of  the  TSE. 

129  ADV_HED.2.5C  -  The  high-level  design  shall  identify  any  underlying  hardware, 
firmware,  and/or  software  required  by  the  TSE  with  a  presentation  of  the 
functions  provided  by  the  supporting  protection  mechanisms  implemented  in  that 
hardware,  firmware,  or  software. 

130  ADV_HED.2.6C  -  The  high-level  design  shall  identify  all  interfaces  to  the 
subsystems  of  the  TSE. 

131  ADV_HED.2.7C  -  The  high-level  design  shall  identify  which  of  the  interfaces  to 
the  subsystems  of  the  TSE  are  externally  visible. 
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132  ADV_HLD.2.8C  -  The  high-level  design  shall  describe  the  purpose  and  method 
of  use  of  all  interfaces  to  the  subsystems  of  the  TSF,  providing  details  of  effects, 
exceptions  and  error  messages,  as  appropriate. 

133  ADV_HLD.2.9C  -  The  high-level  design  shall  describe  the  separation  of  the  TOE 
into  TSP-enforcing  and  other  subsystems. 

Evaluator  action  elements: 

134  ADV_HED.2.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

135  ADV_HED.2.2E  -  The  evaluator  shall  determine  that  the  high-level  design  is  an 
accurate  and  complete  instantiation  of  the  TOE  security  functional  requirements. 

136  Application  Note:  The  elements  within  this  family  define  a  requirement  that  the 
evaluator  determine  that  the  high-level  design  is  an  accurate  and  complete 
instantiation  of  the  TOE  security  functional  requirements.  This  provides  a  direct 
correspondence  between  the  TOE  security  functional  requirements  and  the  high- 
level  design,  in  addition  to  the  pairwise  correspondences  required  by  the 
ADV_RCR  family.  It  is  expected  that  the  evaluator  will  use  the  evidence 
provided  in  ADV_RCR  as  an  input  to  making  this  determination,  and  the 
requirement  for  completeness  is  intended  to  be  relative  to  the  level  of  abstraction 
of  the  high-level  design. 

ADV_IMP.  1  Subset  of  the  implementation  of  the  TSE 
Developer  action  elements: 

137  ADV_IMP.1.1D  -  The  developer  shall  provide  the  implementation  representation 
for  a  selected  subset  of  the  TSE. 

Content  and  presentation  of  evidence  elements: 

138  ADV_IMP.1.1C  -  The  implementation  representation  shall  unambiguously  define 
the  TSE  to  a  level  of  detail  such  that  the  TSE  can  be  generated  without  further 
design  decisions. 

139  ADV_IMP.1.2C  -  The  implementation  representation  shall  be  internally 
consistent. 

Evaluator  action  elements: 

140  ADV_IMP.2.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
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meets  all  requirements  for  content  and  presentation  of  evidence. 

141  ADV_IMP.1.2E  -  The  evaluator  shall  determine  that  the  least  abstract  TSF 
representation  provided  is  an  accurate  and  complete  instantiation  of  the  TOE 
security  functional  requirements. 

ADV_EED.l  Descriptive  low-level  design 
Developer  action  elements: 

142  ADV_EED.1.1D  -  The  developer  shall  provide  the  low-level  design  of  the  TSF. 
Content  and  presentation  of  evidence  elements: 

143  ADV_EED.  1 .1C  -  The  presentation  of  the  low-level  design  shall  be  informal. 

144  ADV_EED.1.2C  -  The  low-level  design  shall  be  internally  consistent. 

145  ADV_EED.1.3C  -  The  low-level  design  shall  describe  the  TSF  in  terms  of 
modules. 

146  ADV_FFD.1.4C  -  The  low-level  design  shall  describe  the  purpose  of  each 
module. 

147  ADV_FFD.1.5C  -  The  low-level  design  shall  define  the  interrelationships 
between  the  modules  in  terms  of  provided  security  functionality  and  dependencies 
on  other  modules. 

148  ADV_FFD.1.6C  -  The  low-level  design  shall  describe  how  each  TSP-enforcing 
function  is  provided. 

149  ADV_FFD.1.7C  -  The  low-level  design  shall  identify  all  interfaces  to  the 
modules  of  the  TSF. 

150  ADV_FFD.1.8C  -  The  low-level  design  shall  identify  which  of  the  interfaces  to 
the  modules  of  the  TSF  are  externally  visible. 

151  ADV_FFD.1.9C  -  The  low-level  design  shall  describe  the  purpose  and  method  of 
use  of  all  interfaces  to  the  modules  of  the  TSF,  providing  details  of  effects, 
exceptions  and  error  messages,  as  appropriate. 

152  ADV_FFD.1.10C  -  The  low-level  design  shall  describe  the  separation  of  the  TOE 
into  TSP-enforcing  and  other  modules. 
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Evaluator  action  elements: 


153  ADV_LLD.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

154  ADV_EED.1.2E  -  The  evaluator  shall  determine  that  the  low-level  design  is  an 
accurate  and  complete  instantiation  of  the  TOE  security  functional  requirements. 

155  Requirements  Overview:  ADV_RCR.l  ensures  that  there  is  consistency  between 
each  level  of  design  decomposition  for  the  TOE.  Each  higher  level  of  design 
decomposition  (the  higher  the  level  of  design  decomposition,  the  more  abstract) 
should  map  to  the  one  below  it,  until  a  level  of  design  decomposition  maps  to  the 
least  abstract  representation,  the  implementation  itself.  Thus,  for  Security  Targets 
derived  from  this  Protection  Profile  there  are  four  layers  of  abstraction  (from  high 
to  low):  the  STs  “TOE  summary  specification”  section,  the  Eunctional 
Specification,  the  high-level  design,  and  the  TOE  itself."^ 

ADV_RCR.  1  Informal  correspondence  demonstration 
Developer  action  elements: 

156  ADV_RCR.1.1D  -  The  developer  shall  provide  an  analysis  of  correspondence 
between  all  adjacent  pairs  of  TSE  representations  that  are  provided. 

Content  and  presentation  of  evidence  elements: 

157  ADV_RCR.1.1C  -  Eor  each  adjacent  pair  of  provided  TSE  representations,  the 
analysis  shall  demonstrate  that  all  relevant  security  functionality  of  the  more 
abstract  TSE  representation  is  correctly  and  completely  refined  in  the  less  abstract 
TSE  representation. 

Evaluator  action  elements: 

158  ADV_RCR.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

159  Application  Note:  The  intent  of  this  requirement  is  for  the  vendor  to  provide,  and 
the  evaluator  to  confirm,  that  there  exists  accurate,  consistent,  and  clear  mappings 
between  each  level  of  design  decomposition.  Thus  there  can  be  no  TOE  security 
functions  defined  at  a  lower  layer  of  abstraction  absent  from  a  higher  level  of 
abstraction  and  vice  versa. 


f  For  related  information,  see  section  4.2.1  in  Part  1  of  the  CC. 
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AGD_ADM.  1  Administrator  guidance 

Developer  action  elements: 

160  AGD_ADM.1.1D  -  The  developer  shall  provide  administrator  guidance  addressed 
to  system  administrative  personnel. 

161  Content  and  presentation  of  evidence  elements: 

162  AGD_ADM.1.1C  -  The  administrator  guidance  shall  describe  the  administrative 
functions  and  interfaces  available  to  the  administrator  of  the  TOE. 

163  AGD_ADM.1.2C  -  The  administrator  guidance  shall  describe  how  to  administer 
the  TOE  in  a  secure  manner. 

164  AGD_ADM.1.3C  -  The  administrator  guidance  shall  contain  warnings  about 
functions  and  privileges  that  should  be  controlled  in  a  secure  processing 
environment. 

165  AGD_ADM.1.4C  -  The  administrator  guidance  shall  describe  all  assumptions 
regarding  user  behavior  that  are  relevant  to  secure  operation  of  the  TOE. 

166  AGD_ADM.1.5C  -  The  administrator  guidance  shall  describe  all  security 
parameters  under  the  control  of  the  administrator,  indicating  secure  values  as 
appropriate. 

167  AGD_ADM.1.6C  -  The  administrator  guidance  shall  describe  each  type  of 
security-relevant  event  relative  to  the  administrative  functions  that  need  to  be 
performed,  including  changing  the  security  characteristics  of  entities  under  the 
control  of  the  TSE. 

168  AGD_ADM.1.7C  -  The  administrator  guidance  shall  be  consistent  with  all  other 
documentation  supplied  for  evaluation. 

169  AGD_ADM.1.8C  -  The  administrator  guidance  shall  describe  all  security 
requirements  for  the  IT  environment  that  are  relevant  to  the  administrator. 

Evaluator  action  elements: 

170  AGD_ADM.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 
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AGD_USR.l  User  guidance 

Developer  action  elements: 

171  AGD_USR.  1 .  ID  -  The  developer  shall  provide  user  guidance. 

Content  and  presentation  of  evidence  elements: 

172  AGD_USR.1.1C  -  The  user  guidance  shall  describe  the  functions  and  interfaces 
available  to  the  non-administrative  users  of  the  TOE. 

173  AGD_USR.1.2C  -  The  user  guidance  shall  describe  the  use  of  user-accessible 
security  functions  provided  by  the  TOE. 

174  AGD_USR.1.3C  -  The  user  guidance  shall  contain  warnings  about  user-accessible 
functions  and  privileges  that  should  be  controlled  in  a  secure  processing 
environment. 

175  AGD_USR.1.4C  -  The  user  guidance  shall  clearly  present  all  user  responsibilities 
necessary  for  secure  operation  of  the  TOE,  including  those  related  to  assumptions 
regarding  user  behavior  found  in  the  statement  of  TOE  security  environment. 

176  AGD_USR.1.5C  -  The  user  guidance  shall  be  consistent  with  all  other 
documentation  supplied  for  evaluation. 

177  AGD_USR.1.6C  -  The  user  guidance  shall  describe  all  security  requirements  for 
the  IT  environment  that  are  relevant  to  the  user. 

Evaluator  action  elements: 

178  AGD_USR.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

179  Application  Note:  This  assurance  component  is  trivially  met  if  neither 

authorized  external  IT  entities  nor  human  users  who  are  not  authorized 
administrators  are  permitted  on  the  TOE.  If  authorized  external  IT  entities  and/or 
human  users  who  are  not  authorized  administrators  are  permitted  on  the  TOE,  it  is 
intended  that  functions  and  interfaces  for  these  users  be  described.  If  the 
developer  permits  human  users  who  are  not  authorized  administrators  on  the 
TOE,  AGD_USR.1.2C  is  not  intended  to  permit  security  functions  or  interfaces  to 
exist  for  such  users  beyond  those  security  functions  described  in  the  CC  class  EIA 
functional  components  in  section  5.1.1.  If  the  developer  does  not  permit  human 
users  who  are  not  authorized  administrators  on  the  TOE,  AGD_USR.1.2C  only 
applies  if  authorized  external  IT  entities  are  permitted. 
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ALC_TAT.  1  Well-defined  development  tools 
Developer  action  elements: 

180  ALC_TAT.1.1D  -  The  developer  shall  identify  the  development  tools  being  used 
for  the  TOE. 

181  ALC_TAT.1.2D  -  The  developer  shall  document  the  selected  implementation- 
dependent  options  of  the  development  tools. 

Content  and  presentation  of  evidence  elements: 

182  ALC_TAT.1.1C  -  All  development  tools  used  for  implementation  shall  be  well- 
defined. 

183  ALC_TAT.1.2C  -  The  documentation  of  the  development  tools  shall 

unambiguously  define  the  meaning  of  all  statements  used  in  the  implementation. 

184  ALC_TAT.1.3C  -  The  documentation  of  the  development  tools  shall 

unambiguously  define  the  meaning  of  all  implementation-dependent  options. 

Evaluator  action  elements: 

185  AEC_TAT.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

186  Application  Note:  There  is  a  requirement  for  well-defined  development  tools. 
These  are  tools  that  have  been  shown  to  be  applicable  without  the  need  for 
intensive  further  clarification.  Eor  example,  programming  languages  and 
computer  aided  design  (CAD)  systems  that  are  based  on  a  standard  published  by 
standards  bodies  are  considered  to  be  well-defined.  The  requirement  in 
AEC_TAT.1.2C  is  especially  applicable  to  programming  languages  so  as  to 
ensure  that  all  statements  in  the  source  code  have  an  unambiguous  meaning. 

ATE_COV.l  Evidence  of  coverage 

Developer  action  elements: 

187  ATE_C0V.1.1D  -  The  developer  shall  provide  evidence  of  the  test  coverage. 
Content  and  presentation  of  evidence  elements: 

188  ATE_C0V.1.1C  -  The  evidence  of  the  test  coverage  shall  show  the 
correspondence  between  the  tests  identified  in  the  test  documentation  and  the  TSE 
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as  described  in  the  functional  specification. 

Evaluator  action  elements: 

189  ATE_C0V.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

ATE_EUN.  1  Eunctional  testing 

Developer  action  elements: 

190  ATE_EUN.  1 .  ID  -  The  developer  shall  test  the  TSE  and  document  the  results. 

191  ATE_EUN.1.2D  -  The  developer  shall  provide  test  documentation. 

Content  and  presentation  of  evidence  elements: 

192  ATE_EUN.1.1C  -  The  test  documentation  shall  consist  of  test  plans,  test 
procedure  descriptions,  expected  test  results  and  actual  test  results. 

193  ATE_EUN.1.2C  -  The  test  plans  shall  identify  the  security  functions  to  be  tested 
and  describe  the  goal  of  the  tests  to  be  performed. 

194  ATE_EUN.1.3C  -  The  test  procedure  descriptions  shall  identify  the  tests  to  be 
performed  and  describe  the  scenarios  for  testing  each  security  function.  These 
scenarios  shall  include  any  ordering  dependencies  on  the  results  of  other  tests. 

195  ATE_EUN.1.4C  -  The  expected  test  results  shall  show  the  anticipated  outputs 
from  a  successful  execution  of  the  tests. 

196  ATE_EUN.1.5C  -  The  test  results  from  the  developer  execution  of  the  tests  shall 
demonstrate  that  each  tested  security  function  behaved  as  specified. 

Evaluator  action  elements: 

197  ATE_EUN.1.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

ATE_IND.2  Independent  testing  -  sample 
Developer  action  elements: 

198  ATE_IND.2.  ID  -  The  developer  shall  provide  the  TOE  for  testing. 
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Content  and  presentation  of  evidence  elements: 

199  ATE_IND.2.1C  -  The  TOE  shall  be  suitable  for  testing. 

200  ATE_IND.2.2C  -  The  developer  shall  provide  an  equivalent  set  of  resources  to 
those  that  were  used  in  the  developer’s  functional  testing  of  the  TSE. 

Evaluator  action  elements: 

201  ATE_IND.2.1E  -  The  evaluator  shall  confirm  that  the  information  provided  meets 
all  requirements  for  content  and  presentation  of  evidence. 

202  ATE_IND.2.2E  -  The  evaluator  shall  test  a  subset  of  the  TSE  as  appropriate  to 
confirm  that  the  TOE  operates  as  specified. 

203  ATE_IND.2.3E  -  The  evaluator  shall  execute  a  sample  of  tests  in  the  test 
documentation  to  verify  the  developer  test  results. 

AVA_SOE.  1  Strength  of  TOE  security  function  evaluation^ 

Developer  action  elements: 

204  AVA_SOE.l.lD  -  The  developer  shall  perform  a  strength  of  TOE  security 
function  analysis  for  each  mechanism  identified  in  the  ST  as  having  a  strength  of 
TOE  security  function  claim. 

Content  and  presentation  of  evidence  elements: 

205  AVA_SOE.l.lC  -  Eor  each  mechanism  with  a  strength  of  TOE  security  function 
claim  the  strength  of  TOE  security  function  analysis  shall  show  that  it  meets  or 
exceeds  the  minimum  strength  level  defined  in  the  PP/ST. 

206  AVA_SOP.1.2C  -  Eor  each  mechanism  with  a  specific  strength  of  TOE  security 
function  claim  the  strength  of  TOE  security  function  analysis  shall  show  that  it 
meets  or  exceeds  the  specific  strength  of  function  metric  defined  in  the  PP/ST. 

Evaluator  action  elements: 

207  AVA_SOE.l.lE  -  The  evaluator  shall  confirm  that  the  information  provided 


This  component  is  intended  to  apply  strictly  to  those  security  functions  that  are  vulnerable  to  an  attack 
involving  a  quantitative  or  statistical  analysis  (e.g.,  password  guessing).  A  short  discussion  of  how  a 
security  mechanism  may  be  vulnerable  is  provided  under  the  “Objectives”  heading  for  AVA_SOF,  in  Part 
3  of  the  CC. 
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meets  all  requirements  for  content  and  presentation  of  evidence. 

208  AVA_SOF.1.2E  -  The  evaluator  shall  confirm  that  the  strength  claims  are  correct. 

209  Application  Note:  The  security  mechanisms  defined  by  the  following 
requirements  have  a  specific  strength  of  function  claim:  FIA_UAU.5.  Section 
5.1.1  of  this  PP  defines  the  specific  strength  of  function  metric  for  each  of  these 
mechanisms. 

AVA_VLA.3  Moderately  resistant 

Developer  action  elements: 

210  AVA_VLA.3.1D  -  The  developer  shall  perform  and  document  an  analysis  of  the 
TOE  deliverables  searching  for  ways  in  which  a  user  can  violate  the  TSP. 

211  AVA_VEA.3.2D  -  The  developer  shall  document  the  disposition  of  identified 
vulnerabilities. 

Content  and  presentation  of  evidence  elements: 

212  AVA_VEA.3.1C  -  The  documentation  shall  show,  for  all  identified 
vulnerabilities,  that  the  vulnerability  cannot  be  exploited  in  the  intended 
environment  for  the  TOE. 

213  AVA_VEA.3.2C  -  The  documentation  shall  justify  that  the  TOE,  with  the 
identified  vulnerabilities,  is  resistant  to  obvious  penetration  attacks. 

214  AVA_VEA.3.3C  -  The  evidence  shall  show  that  the  search  for  vulnerabilities  is 
systematic. 

Evaluator  action  elements: 

215  AVA_VEA.3.1E  -  The  evaluator  shall  confirm  that  the  information  provided 
meets  all  requirements  for  content  and  presentation  of  evidence. 

216  AVA_VEA.3.2E  -  The  evaluator  shall  conduct  penetration  testing,  building  on  the 
developer  vulnerability  analysis,  to  ensure  identified  vulnerabilities  have  been 
addressed. 

217  AVA_VEA.3.3E  -  The  evaluator  shall  perform  an  independent  vulnerability 
analysis 

218  AVA_VEA.3.4E  -  The  evaluator  shall  perform  independent  penetration  testing, 
based  on  the  independent  vulnerability  analysis,  to  determine  the  exploitability  of 
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additional  identified  vulnerabilities  in  the  intended  environment. 


219 


AVA_VLA.3.5E  -  The  evaluator  shall  determine  that  the  TOE  is  resistant  to 
penetration  attacks  performed  by  an  attacker  possessing  a  moderate  attack 
potential. 
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6 


RATIONALE 


6.1 

O.IDAUTH 

O.SINUSE 

O.MEDIAT 

O.SECSTA 

O.ENCRYP 

O.SEEPRO 

O.AUDREC 

O.ACCOUN 

O.SECEUN 


RATIONALE  FOR  IT  SECURITY  OBJECTIVES 

This  security  objective  is  necessary  to  counter  the  threat:  T.NOAUTH  because  it 
requires  that  users  be  uniquely  identified  before  accessing  the  TOE. 

This  security  objective  is  necessary  to  counter  the  threats:  T.REPEAT  and 
T.REPEAY  because  it  requires  that  the  TOE  prevent  the  reuse  of  authentication 
data  so  that  even  if  valid  authentication  data  is  obtained,  it  will  not  be  used  to 
mount  an  attack. 

This  security  objective  is  necessary  to  counter  the  threats:  T.ASPOOE, 
T.MEDIAT  and  T.OEDINE  which  have  to  do  with  getting  impermissible 
information  to  flow  through  the  TOE.  This  security  objective  requires  that  all 
information  that  passes  through  the  networks  is  mediated  by  the  TOE  and  that  no 
residual  information  is  transmitted. 

This  security  objective  ensures  that  no  information  is  compromised  by  the  TOE 
upon  start-up  or  recovery  and  thus  counters  the  threats:  T.NOAUTH  and 
T.SEEPRO. 

This  security  objective  is  necessary  to  counter  the  threats  and  policy: 

T.NOAUTH,  T.PROCOM  and  P. CRYPTO  by  requiring  that  an  authorized 
administrator  use  encryption  when  performing  administrative  functions  on  the 
TOE  remotely. 

This  security  objective  is  necessary  to  counter  the  threats:  T.SEEPRO, 

T.NOAUTH  and  T.AUDEUE  because  it  requires  that  the  TOE  protect  itself  from 
attempts  to  bypass,  deactivate,  or  tamper  with  TOE  security  functions. 

This  security  objective  is  necessary  to  counter  the  threat:  T.AUDACC  by 
requiring  a  readable  audit  trail  and  a  means  to  search  and  sort  the  information 
contained  in  the  audit  trail. 

This  security  objective  is  necessary  to  counter  the  threat:  T.AUDACC  because  it 
requires  that  users  are  accountable  for  information  flows  through  the  TOE  and 
that  authorized  administrators  are  accountable  for  the  use  of  security  functions 
related  to  audit. 

This  security  objective  is  necessary  to  counter  the  threats:  T.NOAUTH, 

T.REPEAY  and  T.AUDEUE  by  requiring  that  the  TOE  provide  functionality  that 
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ensures  that  only  the  authorized  administrator  has  access  to  the  TOE  security 
functions. 


O.LIMEXT  This  security  objective  is  necessary  to  counter  the  threat:  T.NOAUTH  because  it 
requires  that  the  TOE  provide  the  means  for  an  authorized  administrator  to  control 
and  limit  access  to  TOE  security  functions. 

O.EAE  This  security  objective  is  necessary  to  counter  the  threat:  T.MODEXP  because  it 

requires  that  the  TOE  is  resistant  to  penetration  attacks  performed  by  an  attacker 
possessing  moderate  attack  potential. 


T.NOAUTH 

T.REPEAT 

T.REPLAY 

T.ASPOOF 

T.MEDIAT 

T.OLDINF 

T.PROCOM 

T.AUDACC 

T.SELPRO 

T.AUDFUL 

T.MODEXP 

P.CRYPTO 

O.IDAUTH 

X 

O.SINUSE 

X 

X 

O.MEDIAT 

X 

X 

X 

O.SECSTA 

X 

X 

O.ENCRYP 

X 

X 

X 

O.SEEPRO 

X 

X 

X 

O.AUDREC 

X 

O.ACCOUN 

X 

O.SECEUN 

X 

X 

X 

O.EIMEXT 

X 

O.EAE 

X 

Table  6.1  -  Summary  of  Mappings  Between  Threats,  Policies  and  IT  Security  Objectives 


6.2  RATIONALE  FOR  SECURITY  OBJECTIVES  FOR  THE 

ENVIRONMENT 


O.PHYSEC  The  TOE  is  physically  secure. 

O.MODEXP  The  threat  of  malicious  attacks  aimed  at  discovering  exploitable  vulnerabilities  is 
considered  moderate. 
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O.GENPUR 

O.PUBLIC 

O.NOEVIL 

O.SINGEN 

O.DIRECT 

O.NOREMO 

O.REMACC 

O.GUIDAN 

O.ADMTRA 


There  are  no  general-purpose  computing  capabilities  (e.g.,  the  ability  to  execute 
arbitrary  code  or  applications)  and  storage  repository  capabilities  on  the  TOE. 

The  TOE  does  not  host  public  data. 

Authorized  administrators  are  non-hostile  and  follow  all  administrator  guidance; 
however,  they  are  capable  of  error. 

Information  can  not  flow  among  the  internal  and  external  networks  unless  it 
passes  through  the  TOE. 

Human  users  within  the  physically  secure  boundary  protecting  the  TOE  may 
attempt  to  access  the  TOE  from  some  direct  connection  (e.g.,  a  console  port)  if 
the  connection  is  part  of  the  TOE. 

Human  users  who  are  not  authorized  administrators  can  not  access  the  TOE 
remotely  from  the  internal  or  external  networks. 

Authorized  administrators  may  access  the  TOE  remotely  from  the  internal  and 
external  networks 

This  non-IT  security  objective  is  necessary  to  counter  the  threat:  T.TUSAGE  and 
T.AUDACC  because  it  requires  that  those  responsible  for  the  TOE  ensure  that  it 
is  delivered,  installed,  administered,  and  operated  in  a  secure  manner. 

This  non-IT  security  objective  is  necessary  to  counter  the  threat:  T.TUSAGE  and 
T.AUDACC  because  it  ensures  that  authorized  administrators  receive  the  proper 
training. 


T.TUSAGE 

T.AUDACC 

O.GUIDAN 

X 

X 

O.ADMTRA 

X 

X 

Table  6.2  -  Summary  of  Mappings  Between  Threats  and 
Security  Objectives  for  the  Environment 


Since  the  rest  of  the  security  objectives  for  the  environment  are,  in  part,  a  re¬ 
statement  of  the  security  assumptions,  those  security  objectives  trace  to  all  aspects 
of  the  assumptions. 
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6.3 


RATIONALE  FOR  SECURITY  REQUIREMENTS 


222 


FMT_SMR.l 

223 


FIA_ATD.l 

224 


FIA_UID.2 

225 


FIA_UAU.l 

226 


The  functional  and  assurance  requirements  presented  in  this  Protection  Profile  are 
mutually  supportive  and  their  combination  meet  the  stated  security  objectives. 
The  security  requirements  were  derived  according  to  the  general  model  presented 
in  Part  1  of  the  Common  Criteria.  Table  6.3  illustrates  the  mapping  between  the 
security  requirements  and  the  security  objectives.  Table  6.1  demonstrates  the 
relationship  between  the  threats,  policies  and  IT  security  objectives.  Together 
these  tables  demonstrate  the  completeness  and  sufficiency  of  the  requirements. 

The  rationale  for  the  SOF  is  based  on  the  moderate  attack  potential  identified  in 
this  Protection  Profile.  The  security  objectives  imply  the  need  for  probablistic  or 
permutational  security  mechanisms.  The  metrics  defined  in  this  Protection  Profile 
are  acceptable  (i.e.,  passwords)  metrics  to  protect  information  in  DoD  Mission- 
Critical  Categories. 

Security  roles 

Each  of  the  CC  class  FMT  components  in  this  Protection  Profile  depend  on  this 
component.  It  requires  the  PP/ST  writer  to  choose  a  role(s).  This  component 
traces  back  to  and  aids  in  meeting  the  following  objective:  O.SECFUN. 

User  attribute  definition 

This  component  exists  to  provide  users  with  attributes  to  distinguish  one  user 
from  another,  for  accountability  purposes  and  to  associate  the  role  chosen  in 
EMT_SMR.l  with  a  user.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objectives:  O.IDAUTH  and  O.SECEUN. 

User  identification  before  any  action 

This  component  ensures  that  before  anything  occurs  on  behalf  of  a  user,  the  users 
identity  is  identified  to  the  TOE.  This  component  traces  back  to  and  aids  in 
meeting  the  following  objectives:  O.IDAUTH  and  O.ACCOUN. 

Timing  of  authentication 

This  component  ensures  that  users  are  authenticated  at  the  TOE.  The  TOE  is 
permitted  to  pass  information  (aside  from  ETP  and  Telnet  information)  before 
users  are  authenticated.  Authentication  must  occur  whether  the  user  is  a  human 
user  or  not  and  whether  or  not  the  user  is  an  authorized  administrator.  If  the 
authorized  administrator  was  not  always  required  to  authenticate,  there  would  be 
no  means  by  which  to  audit  any  of  their  actions.  An  additional  SOE  metric  for  this 
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requirement  is  defined  in  section  5.1.1  to  ensure  that  the  authentication 
mechanism  chosen  cannot  be  easily  bypassed.  This  component  traces  back  to  and 
aids  in  meeting  the  following  objectives:  O.IDAUTH  and  O.SINUSE. 

FIA_AFL.  1  Authentication  failure  handling 

227  This  component  ensures  that  human  users  who  are  not  authorized  administrators 
can  not  endlessly  attempt  to  authenticate.  After  some  number  of  failures  that  the 
authorized  administrator  decides,  that  must  not  be  zero,  the  user  becomes  unable 
from  that  point  on  in  attempts  to  authenticate.  This  goes  on  until  an  authorized 
administrator  makes  authentication  possible  again  for  that  user.  This  component 
traces  back  to  and  aids  in  meeting  the  following  objective:  O.SEFPRO. 

FIA_UAU.5  Multiple  authentication  mechanisms 

228  This  component  was  chosen  to  ensure  that  multiple  authentication  mechanism  are 
used  appropriately  in  all  attempts  to  authenticate  at  the  TOE  from  an  internal  or 
external  network.  An  additional  SOF  metric  for  this  requirement  is  defined  in 
section  5.1.1  to  ensure  that  the  mechanisms  are  of  adequate  probabilistic  strength 
to  protect  against  authentication  data  compromise.  This  component  traces  back  to 
and  aids  in  meeting  the  following  objective:  O.SINUSE  and  O.IDAUTH. 

FDP_IFC .  1  Subset  information  flow  control  ( 1 ) 

229  This  component  identifies  the  entities  involved  in  the  UNAUTHENTICATED 
information  flow  control  SEP  (i.e.,  users  sending  information  to  other  users  and 
vice  versa).  This  component  traces  back  to  and  aids  in  meeting  the  following 
objective:  O.MEDIAT. 

FDP_IFC.l  Subset  information  flow  control  (2) 

230  This  component  identifies  the  entities  involved  in  the  AUTHENTICATED 
information  flow  control  SEP  (i.e.,  users  of  the  services  FTP  or  Telnet  sending 
information  to  servers  and  vice  versa).  The  users  of  these  services  must  be 
authenticated  at  the  TOE.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objective:  O.MEDIAT. 

FDP_IFF.l  Simple  security  attributes  (1) 

231  This  component  identifies  the  attributes  of  the  users  sending  and  receiving  the 
information  in  the  UNAUTHENTICAED  SEP,  as  well  as  the  attributes  for  the 
information  itself.  Then  the  policy  is  defined  by  saying  under  what  conditions 
information  is  permitted  to  flow.  This  component  traces  back  to  and  aids  in 
meeting  the  following  objective:  O.MEDIAT. 
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FDP_IFF.l  Simple  security  attributes  (2) 

232  This  component  identifies  the  attributes  of  the  users  sending  and  receiving  the 
information  in  the  AUTHENTICAED  SEP,  as  well  as  the  attributes  for  the 
information  itself.  Then  the  policy  is  defined  by  saying  under  what  conditions 
information  is  permitted  to  flow.  This  component  traces  back  to  and  aids  in 
meeting  the  following  objective:  O.MEDIAT. 

PMT_MSA.  1  Management  of  security  attributes  (1) 

233  This  component  ensures  the  TSE  enforces  the  UNAUTHENTICATED_SEP  to 
restrict  the  ability  to  add,  delete,  and  modify  within  a  rule  those  security  attributes 
that  are  listed  in  section  EDP_IEE.  1(1).  This  component  traces  back  to  and  aids  in 
meeting  the  following  objectives:  O.MEDIAT,  O.SECSTA,  and  O.SECEUN. 

EMT_MSA.  1  Management  of  security  attributes  (2) 

234  This  component  ensures  the  TSE  enforces  the  AUTHENTIC ATED_SEP  to 
restrict  the  ability  to  add,  delete,  and  modify  within  a  rule  those  security  attributes 
that  are  listed  in  section  EDP_IEE.  1(2).  This  component  traces  back  to  and  aids  in 
meeting  the  following  objectives:  O.MEDIAT,  O.SECSTA,  and  O.SECEUN. 

EMT_MSA.I  Management  of  security  attributes  (3) 

235  This  component  ensures  the  TSE  enforces  the  UNAUTHENTICATED_SEP  to 
restrict  the  ability  to  create  and  delete  rules  for  security  attributes  that  are  listed  in 
EDP_IEE.1(1).  This  component  traces  back  to  and  aids  in  meeting  the  following 
objectives:  O.MEDIAT,  O.SECSTA,  and  O.SECEUN. 

EMT_MSA.  I  Management  of  security  attributes  (4) 

236  This  component  ensures  the  TSE  enforces  the  AUTHENTIC ATED_SEP  to 
restrict  the  ability  to  create  and  delete  rules  for  security  attributes  that  are  listed  in 
EDP_IEE.1(2).  This  component  traces  back  to  and  aids  in  meeting  the  following 
objectives:  O.MEDIAT  and  O.SECSTA. 

EMT_MSA.3  Static  attribute  initialization 

237  This  component  ensures  that  there  is  a  default  deny  policy  for  the  information 
flow  control  security  rules.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objectives:  O.MEDIAT  and  O.SECSTA. 
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FMT_MTD.l 

238 


FMT_MTD.l 

239 


FMT_MTD.2 

240 


FDP_RIP.l 

241 


FCS_COP.l 

242 


FPT_RVM.l 

243 

FPT_SEP.l 

244 


Management  of  TSF  data  (1) 

This  component  ensures  that  the  TSF  restrict  abilities  to  query,  modify,  delete  and 
assign  certain  user  attributes  as  defined  in  FIA_ATD.1.1  to  only  the  authorized 
administrator.  This  component  traces  back  to  and  aids  in  meeting  the  following 
objective:  O.SECFUN 

Management  of  TSE  data  (2) 

This  component  ensures  that  the  TSE  restrict  abilities  to  set  the  time  and  date  used 
to  form  timestamps  to  only  the  authorized  administrator.  This  component  traces 
back  to  and  aids  in  meeting  the  following  objective:  O.SECEUN. 

Management  of  limits  on  TSE  data 

This  component  ensures  that  the  TSE  restrict  the  specification  of  limits  of  the 
number  of  unauthenticated  failures  to  the  authorized  administrator  and  specifies 
the  action  be  taken  if  limits  on  the  TSE  data  are  reached  or  exceeded.  This 
component  traces  back  to  and  aids  in  meeting  the  following  objective: 
O.SECEUN. 

Subset  residual  information  protection 

This  component  ensures  that  neither  information  that  had  flown  through  the  TOE 
nor  any  TOE  internal  data  are  used  when  padding  is  used  by  the  TOE  for 
information  flows.  This  component  traces  back  to  and  aids  in  meeting  the 
following  objective:  O.MEDIAT. 

Cryptographic  operation 

This  component  ensures  that  if  the  TOE  does  support  authorized  administrators  to 
communicate  with  the  TOE  remotely  from  an  internal  or  external  network  that 
Triple  DES  is  used  to  encrypt  such  traffic.  This  component  is  necessitated  by  the 
postulated  threat  environment.  This  component  traces  back  to  and  aids  in  meeting 
the  following  objective:  O.ENCRYP  and  O.EAE. 

Non-bypassability  of  the  TSP 

This  component  ensures  that  the  TSE  are  always  invoked.  This  component  traces 
back  to  and  aids  in  meeting  the  following  objective:  O.SEEPRO  and  O.SECSTA. 

TSE  domain  separation 

This  component  ensures  that  the  TSE  have  a  domain  of  execution  that  is  separate 
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and  that  cannot  be  violated  by  unauthorized  users.  This  eomponent  traees  baek  to 
and  aids  in  meeting  the  following  objeetive:  O.SELPRO. 

FPT_STM.l  Reliable  time  stamps 

245  FAU_GEN.  1  depends  on  this  eomponent.  It  ensures  that  the  date  and  time  on  the 
TOE  is  dependable.  This  is  important  for  the  audit  trail.  This  eomponent  traees 
baek  to  and  aids  in  meeting  the  following  objeetive:  O.AUDREC. 

FAU_GEN.  1  Audit  data  generation 

246  This  eomponent  outlines  what  data  must  be  ineluded  in  audit  reeords  and  what 
events  must  be  audited.  This  eomponent  traees  baek  to  and  aids  in  meeting  the 
following  objeetives:  O.AUDREC  and  O.ACCOUN. 

FAU_SAR.  1  Audit  review 

247  This  eomponent  ensures  that  the  audit  trail  is  understandable.  This  eomponent 
traees  baek  to  and  aids  in  meeting  the  following  objeetive:  O.AUDREC. 

FAU_SAR.3  Seleetable  audit  review 

248  This  eomponent  ensures  that  a  variety  of  searehes  and  sorts  ean  be  performed  on 
the  audit  trail.  This  eomponent  traees  baek  to  and  aids  in  meeting  the  following 
objeetive:  O.AUDREC. 

FAU_STG.l  Proteeted  audit  trail  storage 

249  This  eomponent  is  ehosen  to  ensure  that  the  audit  trail  is  proteeted  from 
tampering,  the  seeurity  funetionality  is  limited  to  the  authorized  administrator, 
and  that  start-up  and  reeovery  does  not  eompromise  the  audit  reeords.  This 
eomponent  traees  baek  to  and  aids  in  meeting  the  following  objeetives: 
O.SEEPRO,  O.SECSTA  and  O.SECFUN. 

FAU_STG.4  Prevention  of  audit  data  loss 

250  This  eomponent  ensures  that  the  authorized  administrator  will  be  able  to  take  eare 
of  the  audit  trail  if  it  should  beeome  full.  But  this  eomponent  also  ensures  that  no 
other  auditable  events  as  defined  in  FAU_GEN.l  oeeur.  Thus  the  authorized 
administrator  is  permitted  to  perform  potentially  auditable  aetions  though  these 
events  will  not  be  reeorded  until  the  audit  trail  is  restored  to  a  non-full  status.  This 
eomponent  traees  baek  to  and  aids  in  meeting  the  following  objeetives: 
O.SEEPRO,  O.SECSTA  and  O.SECFUN. 
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FMT_MOF.  1  Management  of  security  functions  behavior  (1) 

251  This  component  ensures  that  the  TSF  restricts  the  ability  of  the  TOE  start  up  and 
shut  down  operation  and  multiple  authentication  function  to  the  authorized 
administrator.  This  component  traces  back  to  and  aids  in  meeting  the  following 
objectives:  O.SECSTA,  O.SECEUN,  and  O.EIMEXT. 

EMT_MOE.  1  Management  of  security  functions  behavior  (2) 

252  This  component  was  to  ensure  the  TSE  restricts  the  ability  to  modify  the  behavior 
of  functions  such  as  audit  trail  management,  back  and  restore  for  TSE  data,  and 
communication  of  authorized  external  IT  entities  with  the  TOE  to  an  authorized 
administrator.  This  component  traces  back  to  and  aids  in  meeting  the  following 
objectives:  O.SECSTA,  O.SECEUN,  and  O.EIMEXT. 


O.IDAUTH 

O.SINUSE 

O.MEDIAT 

O.SECSTA 

O.ENCRYP 

O.SELPRO 

O.AUDREC 

O.ACCOUN 

O.SECEUN 

O.LIMEXT 

O.EAL 

EMT_SMR.I 

X 

EIA_ATD.l 

X 

X 

EIA_UID.2 

X 

X 

EIA_AEE.I 

X 

EIA_UAU.5 

X 

X 

EDPJEC.I  (I) 

X 

EDPJEC.I  (2) 

X 

EDPJPE.I  (I) 

X 

EDPJPE.I  (2) 

X 

PMT_MSA.I  (I) 

X 

X 

X 

PMT_MSA.I  (2) 

X 

X 

X 

PMT_MSA.I  (3) 

X 

X 

X 

PMT_MSA.I  (4) 

X 

X 

X 

PMT_MSA.3 

X 

X 

PMT_MTD.I  (I) 

X 

PMT_MTD.I  (2) 

X 

PMT_MTD.2 

X 

PDP_RIP.I 

X 

PCS_COP.I 

X 

PPT_RVM.I 

X 

X 

PPT_SEP.I 

X 

PPT_STM.I 

X 
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O.IDAUTH 

O.SINUSE 

O.MEDIAT 

O.SECSTA 

O.ENCRYP 

O.SELPRO 

O.AUDREC 

O.ACCOUN 

O.SECFUN 

O.LIMEXT 

O.EAL 

PAU_GEN.l 

X 

X 

PAU_SAR.l 

X 

PAU_SAR.3 

X 

PAU_STG.l 

X 

X 

X 

PAU_STG.4 

X 

X 

X 

PMT_MOP.l  (1) 

X 

X 

X 

PMT_MOP.l  (2) 

X 

X 

X 

Table  6.3  -  Summary  of  Mappings  Between  Functional  Requirements  and  IT  Security 

Objectives 

6.4  RATIONALE  FOR  ASSURANCE  REQUIREMENTS 


253  EAL2  Augmented  was  chosen  to  ensure  a  moderate  level  of  security  for 

protecting  information  in  DoD  Mission-Critical  Categories.  Mission-Critical 
Categories  of  information  is  assumed,  by  nature,  to  have  a  greater  threat  for 
disclosure  and/or  corruption  by  unauthorized  parties  as  indicated  in  the  Protection 
Profile  by  the  assumption  A.MODEXP.  To  ensure  the  security  of  Mission-Critical 
Categories  of  information,  not  only  must  vulnerability  analysis  by  the  developer 
be  performed,  but  an  evaluator  must  perform  independent  penetration  testing  to 
determine  that  the  TOE  is  resistant  to  penetration  attacks  performed  by  attackers 
possessing  a  moderate  attack  potential.  This  level  of  testing  is  required  in  this 
Protection  Profile  by  AVA_VEA.3.  As  an  indirect  dependency  of  vulnerability 
analysis,  tools  and  techniques  used  to  develop,  analyze  and  implement  the  TOE 
must  be  identified  and  documented.  This  is  supported  by  the  requirement 
AEC_TAT.l. 


254  Since  the  threat  to  Mission-Critical  Categories  of  information  is  greater,  more 

detailed  product  information  is  required  as  indicated  by  requirements 
ADV_HED.2,  ADVJMP.l,  and  ADV_EED.l  in  this  Protection  Profile.  The 
chosen  assurance  level  as  supported  by  O.EAE  is  consistent  with  the  postulated 
threat  environment.  Specifically,  that  the  threat  of  malicious  attacks  is  not  greater 
than  moderate,  and  the  product  will  have  undergone  vulnerability  analysis  by  the 
developer  and  independent  penetration  testing  by  the  evaluator. 
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6.5  RATIONALE  FOR  NOT  SATISFYING  ALL  DEPENDENCIES 

255  With  the  exception  of  the  functional  component  FCS_COP.  1,  all  dependencies  are 
contained  in  this  Protection  Profile. 

256  Functional  component  FCS_COP.l  depends  on  the  following  functional 
components:  FCS_CKM.l  Cryptographic  key  generation,  FCS_CKM.4 
Cryptographic  key  destruction  and  FMT_MSA.2  Secure  Security  Attributes. 
Cryptographic  modules  used  in  support  of  this  PP  must  be  FIPS  PUB  140-1 
compliant.  If  the  cryptographic  module  is  indeed  compliant  with  this  FIPS  PUB, 
then  the  dependencies  of  key  generation,  key  destruction  and  secure  key  values 
will  have  been  satisfied  in  becoming  FIPS  PUB  140- 1  compliant.  For  more 
information,  refer  to  sections  4.8.1  and  4.8.5  of  FIPS  PUB  140- 1. 
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Acronyms 


257 


The  following  abbreviations  from  the  Common  Criteria  are  used  in  this  Protection 
Profile: 


CC 

EAL 

FIPS  PUB 

IT 

PP 

SEP 

ST 

TOE 

TSC 

TSF 

TSP 


Common  Criteria  for  Information  Technology  Security  Evaluation 
Evaluation  Assurance  Eevel 

Eederal  Information  Processing  Standard  Publication 

Information  Technology 

Protection  Profile 

Security  Eunction  Policy 

Security  Target 

Target  of  Evaluation 

TSE  Scope  of  Control 

TOE  Security  Eunctions 

TOE  Security  Policy 
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